# go-tuf maintainers meeting (2025-09-16)
Attendees:
* Marvin Drees (9elements)
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (Stacklok)

Agenda:
* Finally started rework of our testing code on GitHub
* Pushed initial draft https://github.com/theupdateframework/go-tuf/pull/695
* Will require major refactoring of the testing code but actual program code should remain mostly untouched.
* Published new release 2.2.0 in preparation for the testing

# go-tuf maintainers meeting (2025-05-20)
Attendees:
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (Stacklok)
* Marvin Drees (9elements)
* Marina Moore (Edera)

Agenda:
* No items to discuss

# go-tuf maintainers meeting (2025-04-15)
Attendees:
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (Stacklok)
* Marvin Drees (9elements)
* Marina Moore

Agenda:
* Decision how to handle HTTP 403 vs 404
* https://github.com/theupdateframework/go-tuf/issues/673
* From last TUF community meeting: It's fine if go-tuf diverts from python-tuf
* Wording in spec should be made more clear (TODO)
* We could handle 403 as an error case
* **AI**: Make 403 an error (also bump at least minor version as behavior changed slightly)
* New PR #682 that follows up to the configurable timeout
* Also allows adding more custom fetchers alltogether
* PR still draft but already in acceptable state

# go-tuf maintainers meeting (2025-02-18)
Attendees:
* Fredrik Skogman (GitHub)
* Marina Moore
* Marvin Drees (9elements)

Agenda:
* Differentiate between HTTP 403 and 404 in go-tuf for metadata to not be 'available'
* Same behavior as in python-tuf
* **AI**: Bring up issue in TUF community meeting next time
* Potentially warrants a PR to the spec as it is not entirely clear how different kinds of 'availablitity' should be handled
* Allow for more fetching protocolls other then HTTP
* Not too hard to do in Go but should probably be reflected in other TUF implementations as well
* Proper handling of common error types (like HTTP 404 or 403) should be defined to guarantee same behavior

# go-tuf maintainers meeting (2024-08-20)
Attendees:
* Fredrik Skogman (GitHub)
* Marina Moore
* Radoslav Dimitrov (Stacklok)
* Marvin Drees (9elements)

Agenda:
* Vuln
* Refactor map to linked list should work
* Move signer interface out of sigstore/sigstore and move into secure systems lib and update sigstore/sigstore to use that for the implementation

# go-tuf maintainers meeting (2024-05-21)
Attendees:
* Fredrik Skogman (GitHub)
* Marina Moore (NYU)
* Trishank Karthik Kuppusamy (Datadog)
* Radoslav Dimitrov (Staklock)

Agenda:
* CLI support
* Previous informal consensus was that we could add a CLI on top of something like RSTUF (e.g., tufie)
* Previous go-tuf had a CLI, so users might be anticipating it to return
* If we decide one way or another, we can close issues or keep them open
* CLI is good to get people started, but it is a maintenance nightmare
* Maybe end-users can help us build and maintain a CLI (perhaps tufie as a separate project)
* [Recent vulnerability](https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-fpv2-c7pg-jhr4)
* False positive
* There might be allow-/deny-list in Go to prevent all files from being packaged
* Maybe we have a separate audit repo in the org (the new community repo!)
* Do we have subscriptions to things like Kaspersky via CNCF?
* [No PDFs in the repo right now](https://github.com/search?q=repo%3Atheupdateframework%2Fgo-tuf+path%3A*.pdf&type=code)
* Another strategy: link to PDFs from, say, Markdown
* Any issues from adoptions?
* Everyone seems happy so far
* Lots of great work in fixing issues such as compatibility on Windows
* [Maintainers](https://github.com/orgs/theupdateframework/teams/go-tuf-maintainers)
* [Context](https://github.com/theupdateframework/go-tuf/pull/635#discussion_r1603322722)
* Trishank will send a PR
* There might be some work started soon on a conformance test suite
* Issues such as regenerating static test vectors
* Marina will take a look
* Issue: mismatches in how to compute keyids across clients
* https://github.com/theupdateframework/taps/blob/master/tap12.md
* A multi-client conformance test suite is required to ensure backwards compatibility

# go-tuf maintainers meeting (2023-12-12)
Attendees:
* Marina Moore (NYU)
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (Stacklok)
* Trishank Karthik Kuppusamy (Datadog)

Agenda:
* go-tuf-metadata transition: pr for sigstore, successful release, positive comments from users
* using v2 flag
* replace old code in main branch, users can get new code from "v2"
* Semantic versioning with Go modules
* Test the concept of moving from v1 to v2
* Test on a demo repo so that we don't break anything
* Write down and test the steps
* [Issue](https://github.com/theupdateframework/go-tuf/issues/485#issuecomment-1852170997)
* Fix things like Dependabot to work with the new flow
* Refactoring cosign
* Should the TUF client be refactored independently of sigstore-go?
* The long-term thinking is to bundle go-tuf inside sigstore-go
* sigstore-go will parse the Trusted Root data structure on behalf of cosign

# go-tuf maintainers meeting (2023-11-21)
Attendees:
* Marina Moore (NYU)
* Fredrik Skogman (GitHub)

Agenda:
* Fredrik to look into integrating go-tuf-metadata into sigstore-go
* Trishank briefly discussed Robusto (tech stack of in-toto + TUF + Sigstore)

# go-tuf maintainers meeting (2023-10-17)
Attendees:
* Marina Moore (NYU)
* Fredrik Skogman (GitHub)
* Trishank Karthik Kuppusamy (Datadog)

Agenda:
* Maintainers review
* Follow-up with Zach Newman to see if he can continue to commit time
* Trishank to ask Datadog whether they can contribute a maintainer
* Should we expedite go-tuf-metadata?
* Fredrik: Should we aim to accept it at least as an unstable patch by the end of year?
* TUF testbed
* Radoslav will send link to the repo soon
* Can test both go-tuf-metadata and tuf-js
* CLI vs clients
* Do we want to separate both?
* Do we want to focus language-specific implementations on clients?
* And point users to a single implementation (e.g., python-tuf) for the CLI?
*

# go-tuf maintainers meeting (2023-08-15)
Attendees:
* Marina Moore (NYU)
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (VMware)
* Trishank Karthik Kuppusamy (Datadog)

Agenda:
* Skin in the game (SITG) [Trishank]
* Could we please add at least one maintainer from Sigstore and Datadog to reduce breaking issues?
* Of course, they shouldn't simply be added, but should follow the ladder (e.g., see Sigstore) of contributions, or perhaps we can shortcut more transparently with nominations and voting
* I think this is [the Datadog issue](https://github.com/theupdateframework/go-tuf/pull/522)
* Root issue: public key types, schemes, and values are not concretely defined in TUF
* Fredrik will take a look at this issue in the TUF spec
* Maybe this is best solved in the DSSE layer
* https://github.com/theupdateframework/specification/pull/272
* Maybe a POUF for the DSSE?
* Please review [these slides](https://docs.google.com/presentation/d/1h6Pqq22sbCQjyq0_zs-ijgxxGrcSVea1N-EkRb0y8us/edit#slide=id.p) if you have the time

# go-tuf maintainers meeting (2023-07-18)
Attendees:
* Marina Moore (NYU)
* Zack Newman (Chainguard)
* Fredrik Skogman (GitHub)
* Radoslav Dimitrov (VMware)

Agenda:
* welcome to Fredrik
* followup on AIs from last month
* testing plan
* Marina has student who may be interested
* plan for releasing go-tuf-metadata
* branching vs multiple available at once
* allowing for gradual transition by users
* need a cutoff date
* remove nested clients
* keep the cli, but don't release it
* In any case, we need more maintainers with SITG
* meeting schedule

# go-tuf maintainers meeting (2023-06-20)
Attendees:

Agenda:
* progress on go-tuf
* active maintainers
* plan to reach out to contacts
* fundables
* audit the go-tuf-metadata?
* cross-TUF tests?
* role of go-tuf: why invest here vs. other TUF
* there's a few dependent projects (notably Sigstore, a few private companies)
* should be be investing in a CFFI-compatible library for scalability?
* plan for switch to go-tuf-metadata
* tests are the blocker here
* we have to do this *anyway* for go-tuf-metadata
* can we make these shared? "conformance test rig"
* [proposal](https://docs.google.com/document/d/11bKcRoC0G8b_YnLfK0tj1RfJjrMfXGhO8Li2LA1FUUk/edit?usp=sharing)
* transition plan: new major version
* do we need to maintain both at the same time? maybe not
* AIs
* marina: find someone to do testing
* radoslav: refactor sigstore usage of go-tuf so that there's only one place to change
* later (try to get this scheduled after we get the testing done): security audit of go-tuf-metadata
* go-tuf organization and release w/note about new major version
* marina: trim the maintainers list

# go-tuf maintainers meeting (2023-05-03)
Attendees:
- Marina Moore (NYU)
- Trishank Kuppusamy (Datadog)

## Agenda

* [go-tuf audit](https://github.com/theupdateframework/go-tuf-audit/)
* Consensus between Radoslav, Marina, and Trishank is to let XB41 release the report, and we will file issues shortly to harden go-tuf, but without releasing any security advisory (which we do not feel is needed)
* projects board
* migration plan to go-tuf-metadata
* lib should at least follow best practices in Go
* Must pass enough automated conformance tests
* Should stay good for long enough
* Revisit maintainer list
* Confirm current list
* Get more maintainers
* Attend the Sigstore Golang subgroup meeting?
* Requirements for maintainers?

# go-tuf maintainers meeting (2023-01-04)

Attendees:
- Marina Moore (NYU)
- Radoslav Dimitrov (VMware)
- Joshua Lock (VMware)
- Trishank Kuppusamy (Datadog)

Regrets:
* Asra Ali (Google)

## Agenda

* Clean up projects board
* Flag good-first-issue (just small and big enough) issues for the benefit of GSoC students
* https://github.com/theupdateframework/go-tuf/pull/425
* Hopefully Rado can help review
* Closing 0.6 project in favour of starting a new 0.7 one
* go-tuf-metadata status report (Radoslav) - https://github.com/rdimitrov/go-tuf-metadata
* metadata
* client
* CLI

# go-tuf maintainers meeting (2023-01-04)

Attendees:
- Trishank Kuppusamy (Datadog)
- Marina Moore (NYU)
- Joshua Lock (VMware)

Regrets:
* Asra has a first half conflict.
* Zack is going to miss the whole thing :'(

## Agenda

* [PR 384](https://github.com/theupdateframework/go-tuf/pull/384)
* Could we pls get another approver?
* Key idea: reusing existing preorder DFS code to build a set of valid delegated targets roles by looking at chains of delegations that are responsible for verified targets
* e.g., targets->a->b->c->(some target)
* How do we maintain stability as much as possible considering MAJOR version 0?
* Trying to get more contributors
* Perhaps a good case to start a new repo to replace the current go-tuf

# go-tuf maintainers meeting (2022-12-07)

Attendees:
- Marina Moore (NYU)
- Asra Ali (Google)
- Radoslav Dimitrov (VMware)
- Trishank Kuppusamy (Datadog)

## Agenda
* Delegation seraching update
* punt on this
* bundle with well-known path
* Fulcio TAP
* Implementation: Asra to rebase by end of year, Marina to compare with TAP design
* How to encode public keys?
* Project board review
* Finish up must haves by end of year, cut a release
* New project board in the new year
* go-tuf metadata API
* There is a nice python-tuf-inspired implementation that is almost ready to go public!
* go-tuf maintainers maintenance process
* How should we add/remove maintainers?
* New maintainers should prove a consistent track record
* Not more than 2-3 maintainers from the same org
* https://github.com/sigstore/community/blob/main/MEMBERSHIP.md#triage

## Action Items
* Asra: Fulcio TAP rebase
* Marina: Fulcio TAP feedback, etc
* https://github.com/theupdateframework/go-tuf/issues/272
* Trishank will work with Abhisman to fix this ASAP
* https://github.com/theupdateframework/go-tuf/pull/384
* Trishank to ping Baptiste

# go-tuf maintainers meeting (2022-11-02)

Attendees:
- Marina (NYU)
- Radoslav (VMware)
- Trishank (Datadog)
- Ethan (Datadog)
- Zach (Chainguard)

## Agenda

* #406: On general API for manipulating metadata
* Marina: we need to collectively figure out a good alternative design first
* Zach: concerned that the design lessons from python-tuf would translate 1:1 to go-tuf
* Zach: we should discuss with python-tuf to come up with best practices
* Marina: good ideas like the RepositorySimulator
* General TUF question on delegation searching
* Waiting to hear from Asra, Jussi, and friends
* Started security assessment movement from OSTIF: early Q1 target
* python-tuf just finished its own audit with good results - [Link](https://theupdateframework.github.io/python-tuf/2022/10/21/python-tuf-security-assessment.html)
* [Project 1](https://github.com/orgs/theupdateframework/projects/1/views/1)
* https://github.com/theupdateframework/go-tuf/issues/286
* Zach will try to finish by end of month
* https://github.com/theupdateframework/go-tuf/issues/326
* securesystemslib wants confirmation that they haven't broken us
* Marina is going to report back to securesystemslib
* https://github.com/theupdateframework/go-tuf/issues/272
* Trishank will work with Abhisman to fix this by end of the month
* https://github.com/theupdateframework/go-tuf/pull/384
* Blocking on author to verify delegated targets metadata before writing to storage
* Trishank will reach out to Baptiste
* Project 2
* After wrapping project 1 this month, Radoslav will create a new project 2 that will inherit the backlog from 1
* We plan to make an issue for writing a doc for things we want from the new go-tuf
* Feedback from python-tuf and Datadog folks

# go-tuf maintainers meeting (2022-10-05)

Attendees:
- Joshua
- Asra
- Trishank
- Marina

## Agenda

* [#406](https://github.com/theupdateframework/go-tuf/issues/406): On general API for manipulating metadata
* General TUF question on [delegation](https://github.com/theupdateframework/go-tuf/issues/378) searching
* Typically TUF assumes there is a seperate mechanism for querying, and therefore you are always providing the target path name to the TUF client
* Target discovery may be viewed as a layer on top of a TUF client
* Discovery would be a DFS with a pattern matching
* TUF ls? Hashed bin delegation would be too inefficient
* How to design an **SAFE** API for a user to write their own ./tuf ls
* Something like a VISIT function provided.
* Aim: POC from go-tuf can help inform the other client implementations
* Project planning [Project board](https://github.com/orgs/theupdateframework/projects/1)
* Started security assessment movement from OSTIF: early Q1 target
* Delegated fileMeta PR [#384](https://github.com/theupdateframework/go-tuf/pull/384)
* Backport to 0.3.
* We have done backports before: push to v0.3.x branch
* DataDog / Trishank will do the backport
* 0.4 has too many incompatible changes
* Revisiting the root key incompatible change [#379](https://github.com/theupdateframework/go-tuf/issues/379)

# go-tuf maintainers meeting (2022-09-07)

Attendees:
- Zack Newman (Chainguard)
- Asra
- Marina
- Joshua
- Trishank

## Agenda

* Disclosing [#369](https://github.com/theupdateframework/go-tuf/pull/369) (e.g., Security Advisory, and notifying downstream clients)
* What is the impact?
* Which versions of go-tuf? (Does not seem to be the latest one)
* Can we advise people how to audit for this bug?
* Backport security fix to 0.3.x so that end-users can avoid breaking changes in 0.4.x [done by Zach]
* Automate tooling to create release branches [TODO by Asra]
* Notes about the issue
* The Key IDs must have been distributed in the trusted metadata
* This was vulnerable in old go-tuf that had multiple key IDs
* Anyone with latest version of go-tuf or with single key IDs in the key definition (check date?) will not be affected
* [`SECURITY.md`](https://github.com/theupdateframework/go-tuf/issues/371)?
* Consensus on how to get notified
* Email or Google Forms?
* A Google Groups list to manage access
* Maybe a CNCF-managed email list?
* Two email lists: one to inform maintainers, and the other for maintainers to inform subscribers
* A python-tuf-style [GitHub Action for checking maintainers list every year](https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/maintainer-permissions-reminder.yml)
* Who are all the end-users? Probably notify OSS projects that we know to be publicly using them.
* Or does GitHub advisory do this? Maybe the notifications aren't that useful
* Follow up on versioning/milestones/project plan
* [Project board](https://github.com/orgs/theupdateframework/projects/1)
* Handling [ECDSA key fix](https://github.com/theupdateframework/go-tuf/pull/357)
* Any objections to deprecation package for continued support? No
* Can we issue a "security fix"?
* AI: Create a release for go-tuf after this fix and small advisory on this breaking change.
* Misc
* [Joshua] it would be nice if our PR title lint workflow should checked whether the title matches the "Type of change" checkboxes

## Action Items

- [ ] Trishank: finish publishing #369 advisory
- [ ] Trishank: create email list (CNCF or Google Group), create Google form that sends mail to the email list, create SECURITY.md, copy python-tuf GitHub actionn send PR
- [ ] Zack: backport #369 to `v0.3` ([PR](https://github.com/theupdateframework/go-tuf/pull/375))
- [ ] Asra: file issue about release branch tooling
- [ ] Asra: Finish review comments on the [ECDSA key fix](https://github.com/theupdateframework/go-tuf/pull/357)

# go-tuf maintainers meeting (2022-08-03)

Attendees: Ethan Lowman (Datadog), Marina Moore (NYU/Chainguard), Hossein Siadati (Datadog), Asra Ali (Google), Zack Newman (Chainguard), Trishank Kuppusamy (Datadog), Joshua Lock (VMware)

## Agenda
* Goal of this meeting
* Prioritization
* Timeframes
* Gentle reminder to all the maintainers about misc. go-tuf duties

## Notes

* Sigstore client
* If we're going to have other Sigstore language implementations, they need TUF
* Right now: they should look at `ngclient`, *not* `go-tuf`
* It'd be nice to make go-tuf a better example
* Proposal: ngclient-like effort in TUF.
* It took about a year, but most of it was design
* Perhaps a Go port of python-tuf wouldn't be nearly as much work
* Maybe "go-tuf-on-a-plane (plus 2 weeks quarantine)"
* More people run clients than repos, so probably okay to focus on the client (this seems to be a consensus)
* Writing a simple repository API is easy, anything more complicated is probably going to be repo-specific and so doesn't belong in a general purpose client)
* [Asra] Maybe has a lead on some resources (at GOSST, or via OpenSSF contract work)
* The spec could be improved to make implementation easier
* Roadmap
* Radoslav threw together a [GitHub project](https://github.com/orgs/theupdateframework/projects/1)
* Original motivation: short-term goal to work towards (iterative, regular progress)
* Desire for milestones, which help motivate work
* 2 categories: definitely needs to go in the next release, and nice-to-have in the next release
* We have a lot of users, let's make sure they get fixes quickly
* However we have no project manager---does someone want to take over that role?
* Radoslav would probably do that, but is on leave currently
* [Asra] wants [#270](https://github.com/theupdateframework/go-tuf/pull/270)
* Incremental progress towards better cross-compat
* But just this issue is good to get out soon
* Goal of the next release: cross-compatibility with python-tuf
* The main way we test this is these big Python fixtures
* [Ethan] Would it make sense to have a client/server test matrix?
* [Marina] this has come up in the past as well
* [Trishank] language-independent test fixtures repository?
* [Marina] great place to get involved for Sigstore folks
* [Hossein] I have snippets of code used to generate fixtures (it's rough draft at the moment)
* [Joshua] Python TUF has a "repository simulator"
* Uses metadata API to generate metadata on the fly
* See this [blog post](https://theupdateframework.github.io/python-tuf/2022/06/15/testing-ngclient.html)
* Express test cases as language-independent series of metadata API calls?
* Precursor: go-tuf metadata API?
* [Marina] Every language has an opinion on testing, which makes cross-testing difficult
* [Asra] New repo in theupdateframework for test data?
* Trishank has the power?
* [Joshua] Should we do a patch release soon?
* No objections
* Q: Should we include JSON filestore PR?
* Sigstore wants this
* in "some" release, not necessarily the next one
* Should be pretty doable to merge
* [Asra] wants TAP-4!
* [Trishank] reuse code from Datadog?
* [Asra] One of Fredrik or I will own implementation
* [Asra] Cleanup for delegations
* v1 blocker
* [Hossein] "Break glass" mechanism
* It would be very doable to paint ourselves in a corner if there's a bug
* Maybe via some kind of signatures
* Allows bypassing checks
* It's up to callers to determine what to do in error situations (analogy with TLS)
* Maybe a documentation/example problem? Or a spec problem? To help clients be more robust
* TUF is not designed for "minimal security", it's either full security or nothing at all
* Scenario: clients which are deployed everywhere, then we can't override this manually
* Example: Currently, if you sign things with RSA-PSS in vault, SSLib can't verify. One solution: update go-tuf, but painful to ask clients to do this
* Example: root rotation bug ((old) python-tuf ignores expired roots in between)
* Blog post, like the Google Paxos issues in practice one?
* Resolution: move it to TUF community meeting, with writeup in advance please :)
* [Asra] DSSE
* [Joshua] Move off of CJSON?
* [Asra] keyids (v0.4 milestone)
* They're a list, lots of extra checks around them
* They're just for helping to find the right keys
* [Trishank] we should get rid of it, they're an unfortunate old python-tuf artifact

## AIs

- short-term:
- [asra] #270
- [marina] cut a new patch release
- [zjn] add a tag/milestone for v0.4.0 ("current" vs. "queued" work (backlog)), v1 blockers, put out a call for isues for them
- [ethan] review [JSON filestore PR](https://github.com/theupdateframework/go-tuf/pull/347)
- [marina] make this a recurring meeting (first wednesday of the month)
- [zjn] resolve init-local vs. init (it's deprecated since Feb., rip it out for v0.4)
- [hossein] "Break glass"
- [asra] Key ID cleanup -> v0.4
- medium-term:
- TAP-4 [fredrik/asra]
- go-tuf metdatata API
- DSSE
- long-term: better test suite