tuf v1.1 releases: A Framework for Securing Software Update Systems
The Update Framework (TUF)
The Update Framework (TUF) is written in Python and intended to conform to version 1.0 of the TUF specification. This implementation is in use in production systems but is also intended to be a readable guide and demonstration for those working on implementing TUF in their own languages, environments, or update systems.
About The Update Framework
The Update Framework (TUF) design helps developers maintain the security of a software update system, even against attackers that compromise the repository or signing keys. TUF provides a flexible specification defining functionality that developers can use in any software update system or re-implement to fit their needs.
TUF is hosted by the Linux Foundation as part of the Cloud Native Computing Foundation (CNCF) and its design is used in production by various tech companies and open source organizations. A variant of TUF called Uptane is used to secure over-the-air updates in automobiles.
What TUF Does
In order to securely download and verify target files, TUF requires a few extra files to exist on a repository. These are called metadata files. TUF metadata files contain additional information, including information about which keys are trusted, the cryptographic hashes of files, signatures on the metadata, metadata version numbers, and the date after which the metadata should be considered expired.
When a software update system using TUF wants to check for updates, it asks TUF to do the work. That is, your software update system never has to deal with this additional metadata or understand what’s going on underneath. If TUF reports back that there are updates available, your software update system can then ask TUF to download these files. TUF downloads them and checks them against the TUF metadata that it also downloads from the repository. If the downloaded target files are trustworthy, TUF hands them over to your software update system. See Metadata for more information and examples.
- build: Release process was moved to CD platform (#1946, #1971, #1976)
- build: Build is now reproducible thanks to Hatchling (#1896, #1900)
- build: Build results are now verifiable (#1913, #1926, #1947, #1979)
- build: test dependencies are now pinned for reproducibility (#1867, #1918)
- Metadata API: Validation is now possible during serialization (#1775)
- Infrastructure: Setup development blog (#1886, #1887)
- Metadata API: Supported specification version updated (#1908, #1960)
- Metadata API: unrecognized_fields annotation fix (#1950)
- Metadata API: Constructors are now easier to use (#1922)
- Metadata API: Logging and error message improvements (#1876)
- build: Include examples in source distribution (#1970)
- build: Updated pinned dependency versions
- tests: Various improvements (#1707, #1758, #1808, #1860, #1915, #1936, #1953, #1954, #1955)
Copyright (c) 2010 New York University