f8620c1992
The spec does not say anything about role name uniqueness in a delegations object, but I believe we cannot safely allow multiple roles with the same role name in the roles array of a delegations object. If we did then the roles could have different keyids, and then we would end up in a situation where metadata may be both a valid delegation and an invalid delegation at the same time, depending on how the role gets chosen and that does not seem like the intention of the design. There is an issue open in the specification with number 167 about that issue. Regardless of the Metadata API, I think we should enforce role name uniqueness. I chose to change the data structure containing roles to OrderedDict, where keys are role names and values are DelegatedRole instances. This made sense to me as role names are the unique identifier of a role and their order is important to the way they are traversed afterward. Note: we can't use OrderedDict as type annotation until we drop support for Python 3.6: https://docs.python.org/3/library/typing.html#typing.OrderedDict That's why I used quotes around "OrderedDict" annotation, because I can't import it. Signed-off-by: Martin Vrachev <mvrachev@vmware.com> |
||
|---|---|---|
| .github | ||
| docs | ||
| tests | ||
| tuf | ||
| .fossa.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .readthedocs.yaml | ||
| LICENSE | ||
| LICENSE-MIT | ||
| MANIFEST.in | ||
| pylintrc | ||
| README.md | ||
| requirements-dev.txt | ||
| requirements-docs.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.
The repository currently includes two implementations:
- A legacy implementation, with
tuf/client/updater.pyimplementing the detailed client workflow andtuf/repository_tool.pyproviding a high-level interface for repository operations. The legacy implementation is in use in production systems, but is no longer being actively worked on. - A modern implementation. We are in the process of rewriting the reference
implementation in modern Python
to both: a) address scalability and integration issues identified in
supporting integration into the Python Package Index (PyPI), and other
large-scale repositories, and b) to ensure maintainability of the project.
This implementation consists of:
- a "low-level" metadata API, designed to provide easy and safe access to
TUF metadata and handle (de)serialization from/to files, provided in the
tuf/api/metadata.pymodule. - an implementation of the detailed client workflow built on top of the
metadata API, provided in the
tuf/ngclient/updater.pymodule. The modern implementation is not considered production ready and does not yet provide any high-level support for implementing repository operations, though the addition of API to support them is planned.
- a "low-level" metadata API, designed to provide easy and safe access to
TUF metadata and handle (de)serialization from/to files, provided in the
The reference implementation strives 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.
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.