17f08ad200
Add metadata module with container classes for TUF role metadata, including methods to read/serialize/write from and to JSON, perform TUF-compliant metadata updates, and create and verify signatures. The 'Metadata' class provides a container for inner TUF metadata objects (Root, Timestamp, Snapshot, Targets) (i.e. OOP composition) The 'Signed' class provides a base class to aggregate common attributes (i.e. version, expires, spec_version) of the inner metadata classes. (i.e. OOP inheritance). The name of the class also aligns with the 'signed' field of the outer metadata container. Based on prior observations in TUF's sister project in-toto, this architecture seems to well represent the metadata model as it is defined in the specification (see in-toto/in-toto#98 and in-toto/in-toto#142 for related discussions). This commits also adds tests. **TODO: See doc header TODO list** **Additional design considerations** (also in regards to prior sketches of this module) - Aims at simplicity, brevity and recognizability of the wireline metadata format. - All attributes that correspond to fields in TUF JSON metadata are public. There doesn't seem to be a good reason to protect them with leading underscores and use setters/getters instead, it just adds more code, and impedes recognizability of the wireline metadata format. - Although, it might be convenient to have short-cuts on the Metadata class that point to methods and attributes that are common to all subclasses of the contained Signed class (e.g. Metadata.version instead of Metadata.signed.version, etc.), this also conflicts with goal of recognizability of the wireline metadata. Thus we won't add such short-cuts for now. See: https://github.com/theupdateframework/tuf/pull/1060#discussion_r452906629 - Signing keys and a 'consistent_snapshot' boolean are not on the targets metadata class. They are a better fit for management code. See: https://github.com/theupdateframework/tuf/pull/1060#issuecomment-660056376, and #660. - Does not use sslib schema checks (see TODO notes about validation in doc header) - Does not use existing tuf utils, such as make_metadata_fileinfo, build_dict_conforming_to_schema, if it is easy and more explicit to just re-implement the desired behavior on the metadata classes. - All datetime's are treated as UTC. Since timezone info is not captured in the wireline metadata format it should not be captured in the internal representation either. - Does not use 3rd-party dateutil package, in order to minimize dependency footprint, which is especially important for update clients which often have to vendor their dependencies. However, compatibility between the more advanced dateutil.relativedelta (e.g handles leap years automatically) and timedelta is tested. - Uses PEP8 indentation (4 space) and Google-style doc string instead of sslab-style. See https://github.com/secure-systems-lab/code-style-guidelines/issues/20 - Does not support Python =< 3.5 Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com> Co-authored-by: Joshua Lock <jlock@vmware.com> Co-authored-by: Teodora Sechkova <tsechkova@vmware.com> Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu> |
||
|---|---|---|
| .github | ||
| docs | ||
| tests | ||
| tuf | ||
| .fossa.yml | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| appveyor.yml | ||
| LICENSE | ||
| LICENSE-MIT | ||
| MANIFEST.in | ||
| pylintrc | ||
| README.md | ||
| requirements-dev.txt | ||
| requirements-pinned.txt | ||
| requirements-test.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| tox.ini | ||
A Framework for Securing Software Update Systems
This repository is the reference implementation of The Update Framework (TUF). It 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 companies such as Cloudflare, Datadog, DigitalOcean, Docker, Flynn, IBM, Kolide, LEAP, Microsoft, RedHat, and VMware. A variant of TUF called Uptane is widely used to secure over-the-air updates in automobiles.
Please see the TUF Introduction and TUF's website for more information about TUF!
Documentation
- Introduction to TUF's Design
- The TUF Specification
- Getting Started with the TUF Reference Implementation
- Governance and Maintainers for the reference implementation
- Miscellaneous Docs
Contact
Please contact us via our mailing list. Questions, feedback, and suggestions are welcomed on this low volume mailing list.
We strive to make the specification easy to implement, so if you come across any inconsistencies or experience any difficulty, do let us know by sending an email, or by reporting an issue in the GitHub specification repo.
Security Issues and Bugs
Security issues can be reported by emailing jcappos@nyu.edu.
At a minimum, the report must contain the following:
- Description of the vulnerability.
- Steps to reproduce the issue.
Optionally, reports that are emailed can be encrypted with PGP. You should use PGP key fingerprint E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A.
Please do not use the GitHub issue tracker to submit vulnerability reports. The issue tracker is intended for bug reports and to make feature requests. Major feature requests, such as design changes to the specification, should be proposed via a TUF Augmentation Proposal (TAP).
Limitations
The reference implementation may behave unexpectedly when concurrently downloading the same target files with the same TUF client.
License
This work is dual-licensed and distributed under the (1) MIT License and (2) Apache License, Version 2.0. Please see LICENSE-MIT and LICENSE.
Acknowledgements
This project is hosted by the Linux Foundation under the Cloud Native Computing Foundation. TUF's early development was managed by members of the Secure Systems Lab at New York University. We appreciate the efforts of Konstantin Andrianov, Geremy Condra, Vladimir Diaz, Yuyu Zheng, Sebastien Awwad, Santiago Torres-Arias, Trishank Kuppusamy, Zane Fisher, Pankhuri Goyal, Tian Tian, Konstantin Andrianov, and Justin Samuel who are among those who helped significantly with TUF's reference implementation. Contributors and maintainers are governed by the CNCF Community Code of Conduct.
This material is based upon work supported by the National Science Foundation under Grant Nos. CNS-1345049 and CNS-0959138. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.