joshuagl

Thanks for your comment. I completely agree, and we are working on it. If you have any suggestions for documentation/tutorials/tooling you would like to see, I'd be happy to add them to the list.

We are actively working to improve reference implementation, to make it easier to maintain (easier to read code, type annotations, generally more Pythonic, cleaner design) and use (cleaner documented API, easier to plug in your own implementation of things a content update system might already have an opinionated implementation of -- i.e. the network communication stack).

We hope to build more tools on top of the cleaned up reference implementation once it is feature complete.

For the specification itself, we recently switched to publishing a rich HTML document with cross-linking, syntax highlighting, ToC, etc. https://theupdateframework.github.io/specification/latest/ and added a new section covering some of the repository operations https://theupdateframework.github.io/specification/v1.0.19/#...

I don't expect to change your mind about TUF, though I would love to talk about how Debian could adopt pieces of the TUF design where it makes sense _and_ how TUF might provide affordances to better suit Debian.

For other readers, I think it's important to point out that:

1. TUF does not require use of JSON, or any other specific format.

> Implementers of TUF may use any data format for metadata files as long as all fields in this specification are included and TUF clients are able to interpret them without ambiguity. from https://theupdateframework.github.io/specification/v1.0.19/#...

2. The blog post you link to says that TUF does not handle key revocation. That's untrue. TUF does key revocation explicitly, by replacing the listed keys in the root (for top-level roles) and targets (for delegated roles) metadata, and implicitly through expiration times.