I think we’re good to go, with the caveat that the comparison matrices covering other update frameworks are still somewhat misleading and/or inaccurate (depending on your perspective), and should IMO be disregarded, and ultimately updated or deleted.
Most widely used trusted software update mechanisms can, in practice, check most of the boxes in the matrices, but TUF/Notary consolidates the required functionality into a single, well-defined, reviewed framework.
As long as we’re clear on that, I think that we have all of the info necessary to vote. Thanks to the Notary folks (and @endophage in particular) for your diligence and patience attempting to address all of the questions and concerns expressed.
FYI to the voting TOC members as context, below are a few illustrative comments that have been made by the community regarding the comparison matrices:
FWIW, the YUM part above is not correct as such.
At SUSE we use GPG detach signed YUM repositories and it gives most if not all security features needed.
YUM has a root repomd.xml with sha256 hashes of dependend files all the way down. SUSE and likely others sign to repomd.xml with a trusted GPG key with detached signature.
- freshness: at SUSE we have added an expiry tag to guarantee this
- mix and match: is caught implicitly (the whole YUM repo is signed as a single blob)
- endless data attack: needs to be caught by YUM processing stack, YUM format includes sizes everywhere
- extraneous dependencies: implictly caught (whole YUM state is signed as a single blob)
- fast forward: implicitly caught (whole YUM state is signed as a single blob)
- indefinite freeze: caught by freshness attribute
- malicious mirrors ... well, notary has the same trouble. the freshness will show this to the user.
- rollback attacks: depends on how YUM is used, but RPM based installations usually only have increasing versions only.
- slow retrieval: depends on YUM downloader, but with the sizes known ahead in YUM its at the same level as in TUF
What is a problem is that YUM is a bit RPM centric and does not support plain files, so a new XML part that handles generic files would need to be added.
I also admit that key handling is limited to a single GPG key signing the whole YUM repository instead of multiple roles/keys like in Notary, so some of the key attacks are present in YUM+GPG.
But its not as bad as your graphics makes it to be.
I just spoke to one of the APT developers while at OSS and it appears that Debian/Ubuntu packaging also solves most of the problems you've marked as "not handled" (similarly to what @msmeissn has
been describing for zypper/yumrepo). I would be also shocked to discover that RedHat's dnf and yum do not solve these problems (to the same degree as zypper/apt/etc) as well…
…I agree however, that the comparison table should be updated to match how the actual package
managers in distributions behave to mitigate individual risks.
is clear that many of the Linux vendors have started to construct parts of a protocol set similar to TUF using GPG, but there does not appear to be a formal reviewed specification in the same way as TUF has defined, with detailed security review, at least
as far as I can find. The discussion about which boxes in the table should be ticked, and the fact that no one can easily find definitive answers does suggest that the specification is ad hoc rather than formally specified like TUF, or the answers would be
much easier to find.