Title: [GSoC] Interested in implementing TAP 16 - Snapshot Merkle Trees

[ennie191]

Hi @lukpueh and @JustinCappos,

I hope you’re doing well! My name is Eeshani, and I’m interested in contributing to the implementation of TAP 16 for Snapshot Merkle Trees in the python-tuf project as part of Google Summer of Code (GSoC) 2025.

Before I start working on my proposal, I wanted to reach out and ask a few questions regarding the project:

-Starting the Implementation: Could you provide more detailed guidance on how to begin implementing Snapshot Merkle Trees for TAP 16 in the python-tuf repository? Are there any specific areas or files I should focus on first?

-Testing Strategies: What testing strategies or tools would you recommend for validating the implementation of Snapshot Merkle Trees? Are there existing tests in the repository I should be aware of, or should I create new tests?

-Proposal Expectations: Is there anything specific you would like to see in my GSoC proposal for the implementation of TAP 16 that I might have missed? Any particular focus areas or details that would help you evaluate my proposal more effectively?

I would greatly appreciate any guidance you can offer!

Best regards,
Eeshani (@ennie191)
ennie19105@gmail.com

[lukpueh]

Thanks for creating this issue, @ennie191! I answered a few related questions on the CNCF TUF slack yesterday. Let me re-post here:

There is a proof-of-concept implementation linked from the TAP 16 document (see Augmented Reference Implementation section). It might serve as inspiration but beware:

• It was written with python-tuf <1.0.0, which was very different from the current python-tuf >1.0.0
• It was written for an early draft of the TAP, so it might not be up to date with the current specification

More relevant for the assignment are the recent discussions in the linked issue, which point out flaws in the TAP and make recommendations for improvement. A good path forward could be:

1. Understand TAP
2. Understand issues with TAP as discussed
3. Engage in discussion and make plan for implementation (this could be the original TAP or maybe an improved version right away, or both)
4. Implement and evaluate with regards to discussion

[lukpueh]

Testing Strategies: What testing strategies or tools would you recommend for validating the implementation of Snapshot Merkle Trees? Are there existing tests in the repository I should be aware of, or should I create new tests?

We'll want both regular unit tests, and also test the TAP 16-specific client workflow. You can take a look at python-tuf's test suite, to see examples for both. There is also a blog post about a handy client testing tool called repository simulator.

As a bonus we could run some performance tests to evaluate the assumptions expressed on the linked discussion (most notable #134 (comment)).

[lukpueh]

Proposal Expectations: Is there anything specific you would like to see in my GSoC proposal for the implementation of TAP 16 that I might have missed? Any particular focus areas or details that would help you evaluate my proposal more effectively?

I'd like to see that applicants made an effort in understanding TAP 16 and the related discussions in #134.

[ennie191]

Hi @lukpueh ,

Thank you so much for the detailed response and the valuable resources you’ve shared!

I’ll make sure to go through the proof-of-concept you mentioned in the TAP 16 document and take note of the differences with the current python-tuf version. I understand that it might not be fully up to date with the current specification, but I’ll definitely use it as a starting point.
For the GSoC proposal, I’ll focus on demonstrating a thorough understanding of TAP 16, the related issues, and the potential improvements. I’ll make sure to address all the key aspects in the proposal.

Thanks again for your guidance! I’ll keep you updated on my progress and reach out if I have any further questions.

Best,
Eeshani
@ennie191

[Omarmostafa18]

hi @lukpueh and @JustinCappos
I’m working in my GSoC proposal for TAP 16. Should I include detailed implementation steps (like specific code plans) or focus on a high-level timeline with milestones?

i know The existing TAP 16 PoC is outdated. Can I start rewriting it, or should I wait until the Community Bonding Period if I’m accepted?

If you’re able, could you please review my proposal ? I’d really value your feedback. If you’re too busy, could you share a few tips to make it stronger instead? Let me know how I can share it if you’re up for a review.

this all and thank you in advance.

[lukpueh]

hi @lukpueh and @JustinCappos I’m working in my GSoC proposal for TAP 16. Should I include detailed implementation steps (like specific code plans) or focus on a high-level timeline with milestones?

We don't have hard requirements for the proposal. If you you can come up with an implementation plan, that's great. As I said above, I mainly want to see that applicants sincerely familiarise themselves with the problem space.

i know The existing TAP 16 PoC is outdated. Can I start rewriting it, or should I wait until the Community Bonding Period if I’m accepted?

Sure, you can start contributing any time. Do you know where to start? Maybe you can share a rough plan, before you start submitting code.

If you’re able, could you please review my proposal ? I’d really value your feedback. If you’re too busy, could you share a few tips to make it stronger instead? Let me know how I can share it if you’re up for a review.

Have you submitted your proposal yet?

[Omarmostafa18]

I’ve finished my GSoC proposal ,I haven’t submitted it to GSoC yet I was hoping you could review it first if you’re able, I can send it as a Google Docs so you are able to make comments .

[lukpueh]

Replying to #192 (comment)

From what I gather, TAP 16 introduces snapshot Merkle trees as a replacement for the single snapshot metadata file. One point I plan to explore is whether both should be generated for compatibility or if integrations should still maintain a snapshot role with an associated key when using a Merkle tree-only approach.

That's a deployment decision, which shouldn't be limited by the implementation. Eventually, we want python-tuf, which we'll use to implement this, to support both, so that a TUF integration can use either one of them, or a combination with a fallback or so.

That said, I wouldn't worry too much about backwards-compatibility in the beginning. If we get a working prototype, which we can use to evaluate the idea, that's a great first step.

Additionally, I'll clarify the role of auditors since the TAP currently presents them as both required and optional in different sections.

Good catch! Would you mind adding a comment to #134, ideally with links to the inconsistent parts of the TAP document? This should definitely be clarified.

But it's likely not a problem for the project. As far as I remember, the auditor implementation is independent of the TUF repository and client implementation, which is what we want to focus on first.