Skip to content

RFC - VLC updates and update service on Windows Platforms

Update server for VLC on Microsoft Windows platform

Goal

VLC Media player update management on every Windows platform supported

The main goal is to manage the transition between VLC 3 and VLC 4 on Windows, with each version having different supported OS (VLC3 from XP, VLC4 from Win7).

The second goal is to add more features to the update service, like the ability to test updates, have different channels (release, beta, etc.) and more

Current windows update workflow

Workflow

Update files example

File:

3.0.20
http://get.videolan.org/vlc/3.0.20/win64/vlc-3.0.20-win64.exe
VideoLAN and the VLC development team present VLC 3.0.20 "Vetinari".
VLC 3.0.20 is a medium update to VLC 3.0 branch: it updates codecs, activates AV1 hardware decoding, adds SuperResolution Scaling in hardware, fixes a FLAC issue, important crashes and fixes playback of numerous formats. It also fixes a freeze when using frame-by-frame actions, and a few minor security issues. 3.0.20 adds a few fixes over 3.0.19, notably for crashes and security issues.

signature (.asc):

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRl98a0IGvQV6frc3hxgHE75Y0a3AUCZULebwAKCRBxgHE75Y0a
3D6gAJ9Y5qw3mgCNmC+zjx9+S8xk/EujGwCeIsm0EwOa5iVNm4Z++mbaFtKSKV8=
=7ioe
-----END PGP SIGNATURE-----

Requirements

Features wishlist

  • have distinct policy based on Windows major version ( < win7 -> 3.0.X, >= win7 -> 4.X )
  • need to have some ways to force some given update sequence (example: force update 1 -> 2 and 2 -> 3 instead of directly allow 1 -> 3 update).
  • manage channels, especially: release, beta, nightly channels
  • ability to test updates (by filtering by IP address/CIDR for example)
  • being able to manage full and partial updates, at least for the future (not necessary on first version)
  • update information localization would be very much appreciated
  • good performance (there are hundreds of millions of VLC on Windows, cannot afford a LOT of servers for that).
  • the client part needs to be properly integration in VLC for Windows, meaning:
    • needs to have some C/C++ integration support
    • limit at the very minimum the number of library dependencies
    • compatible with Windows versions from Windows XP to Windows 11
    • compatible with VLC buildsystem and CI (especially cross-compiling on linux for the Microsoft Windows platforms, either with clang or gcc for projects written in C/C+)
    • compatible with VLC license (GPLv2).
  • We need some to have some way to protect some threats on the update system
    • avoid update information spoofing: the idea is to avoid VLC to turn into a DDoS network because some attacker managed to change the update request/reply (by a MitM for example)
    • limit replay attack
    • avoid vulnerability exploitation in case of using parsing systems (ie. xml parsing)
    • if done with a signature system, the signature lifecycle needs to be managed properly

Privacy considerations

VLC is an application famous for its respect of its users privacy. It does not include any analytics system, no cookie-style, no server-side service by default that would be used to leak any personal information.

This is probably that needs to be kept as is for the update service.

As a consequence, a big part of the update computation (determine which version needs to be downloaded) should probably be deported to the VLC app.

Among all the information that could be useful for the update system and probably harmless for the user to be sent:

  • Individual IP address: NOT OK, but this is impossible to avoid because... VLC is sending some request to the update server. At least, we need to have a way to forget this information as soon as possible.
    • note: that does not prevent the service to be able to filter some IPs or networks, for example to be able to achieve some update tests from a given developer/QA IP address
  • OS Version: probably not OK. If the update service get spoofed for whatever reason, some attacker can easily get access to known vulnerabilities (especially on old OS versions) and exploit them.
  • VLC Version: probably not OK. If the update service get spoofed, some attacker can easily get access to known vulnerabilities on older versions of VLC and exploit them.
  • Localization: probably not OK. I suppose VLC selected language is something that users would like to keep private (political reasons?)
  • Update Channel: needed and OK
  • Architecture (x86, x64, arm64, etc.): this is probably OK.
  • System capabilities: We probably need to be careful about that, as the more details are sent to the outside, the easier it is to guess more information on the local system - OS version, drivers version, etc. (Note: this is probably not necessary for now)

Summary: we can probably safely send the update channel and the architecture information.

Statistics

This should probably be a separated topics.

With the given VLC reputation, sending some information that could be useful to have some proper statistics (OS version, VLC version, capabilities, etc.), it looks like the strict minimum would be to ask the User the authorization to send anonymous data.

As it would be optional, there is no real way to use these as a core part of the update system.

New update proposition

Why not use the Windows Store

  • This is not possible on old Windows
  • We experienced many issues and many changes to the store that proved this is not a stable method (Store breaking changes on conditions, unable to update the packaged published, etc.)

Sparkle

Sparkle^[https://github.com/sparkle-project/Sparkle] is the current solution used in VLC macOS. This is not compatible with Windows.

However, there is a Windows version: WinSparkle

Updates are based on "Appcast" feeds, aka a RSS feed^[https://github.com/vslavik/winsparkle/wiki/Appcast-Feeds]

WinSparkle seems to fulfil a lot of requirements:

  • compatible with the privacy principles of VLC
  • distinct policy based on Windows versions
  • force update sequence
  • manage channels
  • it's in C/C++, and maintained
  • few dependencies
  • compabitle with most Windows versions

However, there are some significant drawbacks:

So, VLC cannot use WinSparkle directly... But it could use a similar workflow.

The Sparkle update manifest

The (Win)Sparkle RSS-style principle^[https://github.com/vslavik/winsparkle/wiki/Appcast-Feeds] seems to be a good way to have most of what we need for the manifest format.

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle">
    <channel>
        <title>WinSparkle Test Appcast</title>
        <description>Most recent updates to WinSparkle Test</description>
        <language>en</language>
        <item>
            <title>Version 1.5.5880</title>
            <sparkle:version>1.5.5880</sparkle:version>
            <sparkle:releaseNotesLink>
                https://your_domain/your_path/release_notes.html
            </sparkle:releaseNotesLink>
            <pubDate>Fri, 06 Feb 2016 22:49:00 +0100</pubDate>
            <enclosure url="https://your_domain/your_path/setup.exe"
                       sparkle:dsaSignature="MEQCICh10SofkNHa5iJgVWDi2O8RBYyN+nxkFEL7u/tBuWboAiB6VOV/WQMRJE+kRoICZXAhq5b24WkgqcDs0z7gyBkGVw=="
                       length="0"
                       type="application/octet-stream" />
            <sparkle:minimumSystemVersion>10.0</sparkle:minimumSystemVersion>
            <sparkle:minimumAutoupdateVersion>2.0</sparkle:minimumAutoupdateVersion>
        </item>
    </channel>
</rss>

As VLC already includes some XML parser, it could be implemented without additional dependency.

The XML could be signed through a detached PGP file, or natively (with the signature embedded or external), although checking this type of signature could end adding some additional contrib^[https://www.aleksey.com/xmlsec/].

Recommandation: as macOS version of VLC already uses the Sparkle format for the update, it could be simpler to use the same (XML) structured format, with some possible extension if necessary.

Note: some other structured formats could be used, like some json-based ones. A very popular way is to use the JWT^[https://en.wikipedia.org/wiki/JSON_Web_Token] format (in short, encoding json in base64 and sending the base64 and its signature in a single dot-separated string).

Managing architectures

Here are two simple ways to manage VLC host architecture:

Inside the manifest

WinSparkle added some way to specify one enclosure (downloadable item) per OS+architecture tuple^[https://github.com/vslavik/winsparkle/wiki/Appcast-Feeds#platform-specific-updates]

<item>
    <enclosure sparkle:os="windows" />
    <enclosure sparkle:os="windows-x86" />
    <enclosure sparkle:os="windows-x64" />
    <enclosure sparkle:os="windows-arm64" />
</item>

So the update client just have to check if there is a valid enclosure with a compatible os+architecture version.

This is probably the cleanest way to manage the VLC host architecture, although it might raise the manifest size a little bit.

Outside the manifest

The information can also be included in the publication URL path.

This strategy is safer, BUT this also is less flexible.

URL path: /<update_api_version>/<product=VLC>/<channel>/manifest.xml

Publishing the manifest

URL path: /<update_api_version>/<product=VLC>/<channel>/manifest.xml

Note: we still need to have a way to add more criteria to select the proper manifest AND inside the manifest as well. This can probably done with some symbolic link or similar.

Example: symlink /<update_api_version>/<product=VLC>/<channel>/manifest.xml with /<update_api_version>/<product=VLC>/<channel>/<additional_parameter>/manifest.xml

Manifest Signature

Having the manifest with embedded signature is a plus (half the number of requests on the server), but this is not 100% mandatory.

Providing an external .asc signature file - like the current process - could also solve the problem.

URL path: /<update_api_version>/<product=VLC>/<channel>/manifest.xml.asc

This could also apply the the release notes: we could provide a .asc signature file to check the notes file integrity: for example, if the following is declared in the manifest: <sparkle:releaseNotesLink>https://your_domain/your_path/release_notes.html</sparkle:releaseNotesLink>, the we can generate a https://your_domain/your_path/release_notes.html.asc

On using HTTPS for manifest integrity check

WinSparkle (strongly) suggests to publish the manifest and every other file through HTTPS, to avoid MitM attacks for example.

This is a good advice, but this may not be sufficient for our case.

When downloading the manifest, VLC could try to check the https certificate to check the integrity.

However, a lot of VLC are behind some companies firewalls that are doing so changes on the TLS side (to do some inspection).

So signing the manifest whether it is published through HTTPS or not is probably mandatory.

Implementation suggestions

Client side

There are two main reasonable strategies:

Modifying/Forking WinSparkle

Use the WinSparkle code base but modify it drastically. For the very least:

  • Remove the dependency on OpenSSL and replace it with another crypto lib (gnucrypt/tls)
  • clean/maintain the experimental cmake support
  • add support for the manifest and release notes signature check (through PGP or other system)

Reimplement a light version in VLC

Aka just get some inspiration from WinSparkle while using the same XML format.

The base algorithm can be fairly simple and close to the existing workflow:

  • Download the XML manifest
  • Download the XML manifest signature and check the manifest integrity and signature source (hardcoded)
  • In the manifest, for each item in the channel element:
    • check the version > current VLC version
    • check the minimumAutoupdateVersion >= current VLC version
    • check the minimumSystemVersion >= current OS version
    • if all these checks are ok:
      • download the release notes file and its signature
      • check its signature (integrity and source)
      • show the release notes and ask the user
      • download the updater file and its signature
      • check its signature (integrity and source)

Every significant requirement for this workflow is already available in VLC:

  • Downloading
  • XML parsing
  • Version check
  • Signature check (in PGP)
  • GUI Integration
  • Update launching

Server side

  • The main goal of the server would be to:
    • help generate some clean manifest and manifest signature
    • publish it in HTTP in the proper url tree
  • We can easily add some additional features like:
    • statistics (only for manifest hits)
    • per IP conditional publishing for test purposes only
    • limited A/B testing (see Rollout below)
  • The client side implementation does not NEED a server side at the start
  • The old UpdateServer GSoC code^[https://code.videolan.org/Garf/UpdateServer] can probably be a first code base and heavily modified, but it could also be written from scratch
  • As the server side would mainly be a "RSS update file provider", it could also be easily compatible with the macOS update service.

Testing

We need to test both the server and the client code, optimally together.

Automated tests/CI

  • on VLC side, as the service heavily revolves on manifest files, generating some manifest samples would be sufficient for most unit tests
  • on the update server side, it should be a good idea to include the VLC update code in its unit/functional tests. This could be achieved by either:
    • adding a VLC command line dedicated to the test, with some additional argument to override the update server URL, the signature key, etc. but only for test purpose (the update workflow triggered by VLC cannot be able to override its parameters)
    • or adding a small application sample in the test directory of VLC that could be dedicated to this tests

Manual/pre-release tests

For "real life" tests, the "per IP/CIDR" conditional publication could help test with the real service and real released VLC applications.

Rollout

The original Sparkle includes some simple rollout solution^[https://sparkle-project.org/documentation/publishing/#phased-group-rollouts].

The basic idea:

  • There is a fixed number of rollout groups (7 groups)
  • The client generates a random group ID at installation that is not sent to the server
  • The client uses the group ID to determine which of the 7 rollout groups it is in
  • With the phasedRolloutInterval parameter, the pubDate, and the rollout group, the client determines if the update item is ready to be installed for it.

This looks a fairly simple and functional solution, compatible with VLC (privacy) principles.

Signature lifecycle

At some point, the signature used for manifest (and updater) verification will have to be updated.

To do that, we will need to be able to sign each manifest with different keys, so that both old and new VLC versions can check their hardcoded one.

With detached armor signatures, this should not be a problem: you can concatenate multiple armored keys in the same .asc file, and make some check independently.

This is even officially supported by GPG:

$ cat all.asc # a concatenation of two signatures of the same file with two different keys

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSwBlsEAPDOKJArc01qjAzsOsYcuwUCaP4nkwAKCRBqjAzsOsYc
u/zxAQCKes+S+b0HiONl/bybsFxxO9Frijc9GYibFte0L+YViAD/eQ5Xk1uVmTpS
QoM34B7rJ6AIgLg26+GgcjN8RsHn5Qg=
=PwIo
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTHIZ8Wod5s7UvRWOsfbInj+o2Q8gUCaP4niAAKCRAfbInj+o2Q
8my8AP9K8CSVSdhnHQmw6Egul6cNljqzgrAQNqawF28qeNQMYAEA5WyBQCb0mDI6
Mw69qH0+sDWSHf1ZeMK4g88r9CKdVAM=
=k6fC
-----END PGP SIGNATURE-----

$ gpg --assert-signer C7219F16A1DE6CED4BD158EB1F6C89E3FA8D90F2 --verify all.asc test # check against one particular key

gpg: Signature made Sun 26 Oct 2025 02:52:19 PM CET
gpg:                using EDDSA key B0065B0400F0CE28902B734D6A8C0CEC3AC61CBB
gpg: Good signature from "test1 <test1@example.com>" [ultimate]
gpg: Signature made Sun 26 Oct 2025 02:52:08 PM CET
gpg:                using EDDSA key C7219F16A1DE6CED4BD158EB1F6C89E3FA8D90F2
gpg: Good signature from "test2 <test2@@example.com>" [ultimate]
gpg: asserted signer 'C7219F16A1DE6CED4BD158EB1F6C89E3FA8D90F2'

$ echo $? # returns OK
0

Beta/nightly channel update

Channel manifest integration

Even if the Sparkle manifest allows to define multiple channels in the same file, it does not seem to be suitable for VLC usecases: due to the (very) high number of requests/downloads on this file, raise the size of the manifest significantly would need far more bandwidth on the server side, for very little advantages.

It seems more reasonable to provide one manifest file per channel (release, beta, nightlies, etc.), and have the user decide (in VLC settings for example) which channel he/she wants to select.

The "real" beta/nightly problem

Even though the new update service could be able to provide some beta/nightly update channel, this does not resolve the beta/nightly channel artifacts signature.

It is very unlikely that the current nightlies worklow can work with the new update .exe file not signed properly. It would be downloaded, but not executed by Windows (security alert).

On top of that, non-signed binaries (dlls, etc.) might also be flagged as dangerous by the Windows security suite.

As a consequence, (automatic?) signing process should probably be added to these channels, which also raise the security measures related to that.

Annex: other existing (open source) solutions

balrog

Mozilla Balrog is a complete (complex?) update server designed to handle massive deployments for Firefox and Thunderbird.

Technical Architecture:

Core Philosophy:

This is the exact opposite philosophy compared to Sparkle - the update computation is done remotely through a sophisticated rule-based system:

  • Rule-based matching: Database-driven ruleset determines which updates to serve
  • Client profiling: Client parameters sent via URL path: /update/6/<product>/<version>/<buildID>/<buildTarget>/<locale>/<channel>/<osVersion>/<systemCapabilities>/<distribution>/<distVersion>/update.xml?force=1
  • XML output: Returns XML response with update metadata and download links
  • Multi-channel support: Handles release, beta, nightly, and custom channels

Advanced Features:

  • Signoff requirements: Multi-person approval system for critical updates
  • Background rate control: Gradual rollout capabilities (throttling)
  • Fallback rules: Multiple rule priorities and fallback mechanisms
  • Test channels: Verification environment before production deployment
  • Change tracking: Complete audit trail with blame attribution and rollback capabilities
  • Release management integration: Automated integration with Mozilla's release pipeline

Security Implementation:

  • MAR file signing
  • Chain of trust verification: Ensures updates come from authorized sources
  • GPG signing: Additional integrity verification for source verification
  • Code signing: Integration with Mozilla's certificate infrastructure
  • Multi-layer verification: Both transport and content-level security

Scalability Features:

  • Efficient matching: Optimized rule evaluation algorithms
  • CDN integration: Works with content delivery networks for global distribution
  • Performance monitoring: Built-in metrics and monitoring capabilities

Evaluation Against VLC Requirements:

Pros:

  • Security features: Multiple layers of signature verification, code signing, and chain of trust
  • Windows version support: Can easily implement policies based on Windows version through rule matching
  • Multi-channel support: Native support for release/beta/nightly channels
  • IP filtering/testing: Background rate control and test channels enable controlled rollouts
  • Signature lifecycle: Comprehensive key management and rotation capabilities
  • Performance: Designed for high-performance update serving at global scale
  • Localization support: Built-in locale parameter handling

Cons:

  • Complexity: Significant infrastructure overhead - requires database, admin interfaces, monitoring
  • Privacy concerns: Requires detailed client metadata transmission (OS version, system capabilities, etc.)
  • Deployment complexity: Requires substantial server infrastructure and operational expertise

libautoupdate

libautoupdate is a minimalist cross-platform C library designed for self-updating applications.

Technical Architecture:

  • Repository: https://github.com/pmq20/libautoupdate
  • Implementation: Pure C library with minimal dependencies
  • Platforms: Windows, macOS, Linux (Unix-like systems)
  • License: MIT License (GPLv2 compatible)
  • Dependencies: Only zlib for ZIP compression support

Core Update Mechanism: Simple two-round HTTP communication process:

  1. Round 1 - Version Check: HTTP/1.0 HEAD request to check latest version

    • Server responds with HTTP 302 Found and Location header containing version
    • Compares Location header content with current version string
    • Proceeds to download if version differs

  2. Round 2 - Download: HTTP/1.0 GET request to download update

    • Server responds with 200 OK transferring new release
    • Supports gzip and ZIP compressed downloads
    • Content-Type header determines decompression method

Implementation Features:

  • Single API function: autoupdate() provides complete update functionality
  • Frequency limiting: Once-per-24-hours check using ~/.libautoupdate cache file
  • Self-replacement: Downloads to temporary directory, then replaces current executable
  • Platform-specific handling: Windows API vs POSIX file operations
  • Error handling: Comprehensive error checking and reporting
  • CI override: CI=true environment variable prevents updates

Update Process Flow:

  1. Check if update necessary (time-based and version comparison)
  2. Connect to specified host/path
  3. Retrieve update location via HTTP headers
  4. Download and validate update package
  5. Inflate/decompress if needed (ZIP/gzip support)
  6. Write new executable to system temporary directory
  7. Replace current executable preserving permissions
  8. Optionally restart application

Evaluation Against VLC Requirements:

Pros:

  • C/C++ integration: Pure C library with minimal dependencies, perfect for VLC's codebase
  • Cross-platform: Native support for Windows (including XP), macOS, and Linux
  • Minimal dependencies: Only requires zlib, fits VLC's minimal dependency requirement
  • GPLv2 compatible: MIT License allows integration with VLC's GPLv2 license
  • Cross-compilation friendly: Simple C code should work with VLC's cross-compilation setup
  • Lightweight: Single function API with minimal overhead
  • Self-contained: No external infrastructure requirements beyond web server
  • Windows XP support: Pure C implementation compatible with older Windows versions

Cons:

  • No signature verification: Downloads over HTTP/HTTPS without cryptographic verification
  • No security features: Lacks PGP signing, code signing, or integrity checks
  • No channel support: Cannot distinguish between release/beta/nightly channels
  • No Windows version policies: No built-in mechanism for version-specific update rules
  • No IP filtering: No server-side control for staged rollouts or testing
  • Limited scalability features: Simple HTTP requests without load balancing or CDN integration
  • No localization support: Update messages and metadata not localizable
  • No partial updates: Only supports full executable replacement
  • Basic protocol: Simple HTTP-based protocol without modern security practices
  • No signature lifecycle management: No key rotation or certificate management

Critical Security Gap: The library's documentation indicates it "appears to download app updates over plaintext, unauthenticated, HTTP" with "ad-hoc HTTP parsing, no usage of a library." This represents a significant security vulnerability that would need to be addressed for VLC's requirements.

Google omaha

Google Omaha is an enterprise-grade update framework used by Chrome, Edge, and other Google products to manage software updates for millions of devices worldwide.

Technical Architecture:

  • Repository: https://github.com/google/omaha
  • Implementation: C++ (91.6% of codebase) with COM architecture
  • Platforms: Windows 7, 8, and 10 (Windows XP explicitly not supported)
  • License: Apache 2.0 License
  • Dependencies: Visual Studio 2022, Windows SDK, Python 2.7, SCons, multiple third-party libraries

Core Architecture Components: Omaha consists of three fundamental components:

[Omaha Client] <--COM RPC--> [Update3 COM Server] <--network--> [Omaha Update Server]
  • Omaha Client: User-facing application that initiates update checks
  • Update3 COM Server: Background service handling update logic with appropriate privileges
  • Omaha Update Server: HTTP(S) server accepting XML requests and serving update responses

Update Mechanism:

  • Installation Types: User-level (AppData) or Machine-level (Program Files) installations
  • Background Updates: 24-hour scheduled checks via Windows Task Scheduler
  • Privilege Handling: Separate COM server runs with installation privileges while client apps run unprivileged
  • Update Process: 1MB online installer → Omaha setup → background update checks → automatic updates

Security Implementation:

  • Client Uptake Protocol (CUP): Cryptographic protection for update requests/responses
    • Request authentication via signature proving client's private key
    • Key exchange with nonce protection against replay attacks
    • Encrypted communication using client's private verification key
  • SSL/TLS Support: Secure channel option for update communication
  • Binary Verification: Hash and size verification for downloaded updates
  • Protected Downloads: Access token support for sensitive content over SSL

Protocol Specifications:

  • Server Protocol V3: XML-based HTTP(S) communication
  • Version Management: 4-tuple dot-decimal notation (e.g., 1.0.66.44)
  • Privacy Features: Multiple user counting algorithms, randomized IDs, opt-in tracking
  • Multi-platform Support: Windows, Mac, Linux, iOS, Android

Development Requirements:

  • Build Environment: Visual Studio 2022, Windows SDK 10.0.22621.0
  • Complex Dependencies: WTL, WiX Toolkit, Protocol Buffers, Breakpad, GoogleTest, libzip, zlib
  • Non-hermetic Build: Manual dependency resolution and environment configuration
  • Customization Required: Hard-coded values (server URLs, registry keys) require C++ source modifications

Evaluation Against VLC Requirements:

Pros:

  • Proven massive scale: Successfully handles updates for hundreds of millions of Chrome installations
  • Enterprise-grade security: CUP protocol, SSL/TLS, binary verification, and cryptographic protections
  • Windows expertise: Deep Windows integration with COM, Task Scheduler, and privilege management
  • Multi-channel capable: Protocol supports different update channels and staged rollouts
  • Robust architecture: Separate privilege domains for security and reliability
  • Background operation: Non-intrusive automatic updates via system scheduler
  • Hash verification: Built-in integrity checking for downloaded updates

Cons:

  • Windows XP incompatibility: Explicitly dropped Windows XP support due to technical issues
  • Apache 2.0 license conflict: Incompatible with VLC's GPLv2 license due to patent clauses
  • Massive complexity: Requires Visual Studio, multiple SDKs, and complex third-party dependencies
  • Hard-coded customization: Requires forking and modifying C++ source code for deployment
  • Heavy infrastructure: Needs dedicated server implementation and complex build environment
  • No cross-compilation support: Windows-only development environment incompatible with VLC's Linux cross-compilation
  • Excessive dependencies: Conflicts with VLC's minimal dependency requirements
  • MSVC requirement: Incompatible with VLC's GCC/Clang cross-compilation toolchain
  • No signature lifecycle: While secure, doesn't match VLC's existing PGP-based signing approach
  • Development overhead: "Not hermetic" build process with manual dependency management

Critical Incompatibilities:

  1. Legal: Apache 2.0 license fundamentally incompatible with GPLv2 due to patent termination clauses
  2. Platform: No Windows XP support conflicts with VLC's compatibility requirements
  3. Technical: MSVC-only build system incompatible with VLC's cross-compilation infrastructure

wyupdate

This is a C# solution only, and not updated since 5 years.

Inkscape

Inkscape does not have a built-in automatic update system for Windows. Manual updates are required through:

  • Microsoft Store version: Provides automatic updates via Windows Store mechanism
  • WinGet: Command-line package manager can handle updates with winget upgrade --id 'Inkscape.Inkscape'
  • Manual download: Users must visit the website, download new versions, and manually uninstall the old version before installing the new one

Blender

Blender lacks native automatic updates but offers several update paths:

  • Microsoft Store version: Automatic updates through Windows Store
  • Steam version: Automatic updates through Steam platform
  • Blender Launcher: Third-party open-source tool that manages multiple Blender versions and provides one-click updates

Blender Launcher Technical Details

Architecture:

  • Written in Python with PySide6 GUI framework
  • Cross-platform support (Windows 64-bit, Linux GLIBC 2.31+)
  • Distributed via GitHub releases

Version Detection System:

  • Uses JSON-based API files to store version information
  • Maintains local cache of version data for faster startup
  • Automatic checking of latest builds from multiple sources:
    • Stable releases from blender.org
    • Daily builds from builder.blender.org
    • Experimental branches

Key Libraries:

  • semver: Semantic versioning for complex version parsing and comparison
  • BeautifulSoup4: HTML parsing for scraping version information
  • urllib3: HTTP client with SOCKS proxy support for downloads
  • dateparser: Parsing commit timestamps for version ordering
  • lxml: XML/HTML processing

Version Management Features:

  • Sophisticated version matching with query syntax (e.g., "^.^.*" for latest version, "4.*.^" for latest patch in v4)
  • Support for LTS (Long Term Support) version identification
  • Build metadata extraction including commit hashes, branch names, and timestamps
  • Platform-specific executable detection and launch capabilities

Publishing Mechanism:

  • Monitors official Blender download endpoints
  • Caches build information in .blinfo JSON files
  • Version comparison using semantic versioning with custom extensions for Blender's naming conventions
  • Supports multiple release channels (stable, daily, experimental)

Network Management:

  • Configurable proxy support (HTTP, HTTPS, SOCKS4a, SOCKS5)
  • Custom TLS certificate support
  • Request rate limiting and connection pooling
  • Unique user agent generation for tracking
  • Manual updates: Traditional download from blender.org

Audacity

Audacity has a controversial update system:

  • Update checking: Checks for updates on launch and every 12 hours, but officially requires user consent
  • User reports: Some users report experiencing automatic updates without consent, despite official policy
  • Enterprise concerns: System administrators can disable update checks via registry for corporate environments
  • Silent installation: Supports silent installation using /VERYSILENT /NORESTART flags

KeePass

KeePass deliberately avoids automatic updates:

  • Manual-only approach: No built-in automatic update system
  • Update notifications: Checks for updates but always requires user decision
  • EarlyUpdateCheck plugin: Third-party plugin provides enhanced update functionality with one-click updates
  • Portable support: Plugin can detect installation type (installer, portable, MSI) and handle updates accordingly

Krita

Krita provides automatic updates only through app stores:

  • Microsoft Store: Automatic updates for Windows 10+ users
  • Steam Store: Automatic updates through Steam platform
  • Epic Games Store: Automatic updates through Epic platform
  • Manual updates: Free version from krita.org requires manual download and installation

VSCode

VSCode has a sophisticated automatic update system:

  • Monthly releases: Ships with auto-update support when new releases are available
  • Installation-dependent behavior: User installations get full auto-updates, system installations have limitations
  • Administrator limitations: Running as administrator disables auto-update functionality
  • Manual override: "Check for Updates" option available in Help menu
  • Enterprise configuration: Supports proxy environments and network-restricted deployments

Android Studio

Android Studio uses JetBrains' update infrastructure:

  • JetBrains Toolbox: Manages automatic updates for all JetBrains tools including Android Studio
  • Manual installation: Notifies users via bubble dialog when updates are available
  • Elevator.exe: Windows component handles UAC elevation during updates
  • Update scheduling: Can be configured for automatic updates or manual approval
  • Toolbox App 2.0: Provides background downloads and "Update Pending" states

Brave Browser

Brave adapts Chromium's update system with custom components:

  • Chromium-based updater: Uses adapted version of Chromium's update mechanism
  • Task Scheduler integration: Uses BraveSoftwareUpdateTaskMachineUA or BraveSoftwareUpdateTaskUser tasks
  • Custom infrastructure: Replaces Google's update components with Brave-specific ones
  • Windows version support: Automatic updates support Windows 10+ (Windows 7 requires manual updates)
  • Component updates: Separate system for updating browser components

Signal Desktop

Signal uses Electron's update framework:

  • electron-updater: Built on electron-updater package with enhanced functionality
  • Squirrel.Windows: Uses Squirrel.Windows as underlying update framework
  • Automatic detection: Periodically checks for updates and during startup
  • Staged rollouts: Supports distributing updates to subset of users initially
  • Code signing: Validates signatures on both Windows and macOS
  • Background downloads: Downloads updates automatically if configured

7-Zip

7-Zip has no native automatic update system:

  • Manual-only: Requires manual download and installation from official website
  • Third-party solutions: Ninite, PowerShell scripts, and enterprise management tools can automate updates
  • PatchMyPC: Free updater tool can manage 7-Zip updates
  • Enterprise deployment: Microsoft Intune and similar tools can manage updates in corporate environments

OBS Studio

OBS Studio provides update notifications but requires manual installation:

  • Update checking: Can automatically check for updates on startup
  • Notification system: Alerts users when new versions are available
  • Manual installation: Users must download and install updates manually
  • Settings storage: Update preferences stored in global.ini file
  • No silent updates: Designed to give users control over when updates are applied

Others

curl https://update-mar.libreoffice.org/update/check/1/LibreOffice/87fa9aec1a63e70835390b81c40bb8993f1d4ff6/Windows_X86_64/LOOnlineUpdater

{
    "from": "87fa9aec1a63e70835390b81c40bb8993f1d4ff6",
    "see also": "",
    "update": {
        "hash": "a35ec599e5c95e53a54f0637d2e69a6757bdf55fee61c7fbb8ad0c6f8bd5a4275ebbc7785ed78a1263e421c1a6e62295c1a39c1419dcd712ce62ba8029c34cae",
        "hash_function": "sha512",
        "size": 20281080,
        "url": "https://update-pool.libreoffice.org/24.8.2.1/LibreOffice_24.8.2.1_Windows_X86_64_0f794b6e29741098670a3b95d60478a65d05ef13_from_87fa9aec1a63e70835390b81c40bb8993f1d4ff6_partial.mar"
    },
    "languages": {}
}
Edited by Simon Latapie

VideoLAN code repository instance