TAP Acceptance at TUF Community Meeting

Skip to first unread message

Marina Moore

Nov 29, 2021, 2:59:40 PM11/29/21
to The Update Framework (TUF)

At the next TUF community meeting [1] on December 15 at 11am EST, we will be discussing whether to move TAPs 13 [2] and 15 [3] from draft to accepted. If you are interested, please review these TAPs before the meeting and either leave comments on the corresponding GitHub issues [4][5] or bring them to the meeting.

We will also have a discussion of TAP 16 [6], but do not plan to move this to the accepted state until the related RSA accumulator proposal is finished.

Hope to see you all there!


Justin Cappos

Nov 29, 2021, 11:07:21 PM11/29/21
to Marina Moore, The Update Framework (TUF)
FYI: I have proposed a very minor clarification to the text of TAP 13, which likely may be merged in before the meeting.  It merely tries to expand a little on how a top-level targets file compromise differs.  https://github.com/theupdateframework/taps/pull/145


You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/CAHYnHHanMbZ0mw%2Byi-aRb8VSf_L_5MDtvW2CWoYF0c6%3DLJPi-w%40mail.gmail.com.

Joshua Lock

Dec 10, 2021, 11:44:06 AM12/10/21
to Marina Moore, The Update Framework (TUF)

Unfortunately, I won’t make the community meeting next week, so I have been looking at TAPs 13 and 15.


TAP 15 seems in a good place to move to accepted. It’s a relatively small and optional change which is an easy win for reducing the size of the top-level targets metadata when using hashed bin delegations.

I’d really like to see it accepted and implemented in python-tuf before PyPI/warehouse rolls out its TUF integration.

(I opened a minor clarity PR against the TAP https://github.com/theupdateframework/taps/pull/146)


TAP 13 I like a lot but there are still open questions (https://github.com/theupdateframework/taps/issues/137) around the mapping metadata format, whether the client can provide a top-level targets metadata file (rather than just map to repository hosted metadata), and how the TAP interacts with TAP 4. I’ve added some thoughts on these in the issue, but tl;dr I think we need to figure out how TAP 13 interacts with TAP 4 before we move TAP 13 to accepted.

I’d also really like to see a PoC for TAP 13 built on the refactored python-tuf.





Joshua Lock

VMware Open Source Technology Center


Reply all
Reply to author
0 new messages