TUF Community Meetings

# TUF Community Meetings ## Call information * Fourth Wednesday of the month 11am ET (8am PT) * meet.google.com/jhk-cvuf-icd ## January 25, 2023 Meeting ## November 30, 2022 Meeting ### Attendees * Marina Moore (NYU) * Fridolin Pokorny (Datadog) * Trishank Karthik Kuppusamy (Datadog) * Joshua Lock (VMware) * Justin Cappos (NYU) * Aditya Sirish (NYU) * Renata Vardena (OpenLawLibrary) * Ruben Gonzalez (Radboud University) ### Agenda * Introductions * Project updates * ITE-2 tooling work: what are the usability requirements for using this in python-tuf? * Merkle DAG TAP * TAP 8 updates and implementation * go-tuf #425 * next meeting ### Notes * TUF & SPHINCS+ integration update * In securesystemslib * SSLib recently added support for generic key backends * Example: https://github.com/secure-systems-lab/securesystemslib/pull/442 * Datadog could and would like to add support for Hashicorp Vault as a first-class backend in SSLib * Fulcio TAP status * ITE-2 tooling work * https://github.com/in-toto/ITE/blob/master/ITE/2/README.adoc * Releasing TUF with TUF + in-toto: what are the usability requirements for tooling? * Datadog is interested in collaborating * Aditya to organise an informal meeting * Merkle DAG TAP * https://github.com/theupdateframework/taps/pull/156 * Primary use case: recording state of git repos for IPFS * Draft PR for IPFS hopefully next month * Looking for feedback * TAP 8 * https://github.com/theupdateframework/taps/blob/master/tap8.md * In-band key rotation TAP * Primary use case now: rotating Fulcio keys * PEP 458 * Latest update unknown * We should follow up * go-tuf * https://github.com/theupdateframework/go-tuf/pull/425 * Abhisman will raise the issue on #go-tuf Slack * Misc updates * Kubecon EU * Maintainer track CFP is open * Contribfest will also be open * In-person working session next year * Around March 2023? ## September 28, 2022 Meeting ### Agenda * Project updates * Introductions * Hacktoberfest? * [TUF + in-toto contribfest ideas](https://hackmd.io/_XBncm2hQ06gUHkxlQQJYw) ## August 24, 2022 Meeting ### Agenda * Project updates * Introductions ### Attendees * Martin Vrachev (VMware) * Joshua Lock (VMware) * Marina Moore (NYU/Chainguard) * Zack Newman (Chainguard) * Justin Cappos (NYU) * Trishank Karthik Kuppusamy (Datadog) * Sebastien Awaad (Anaconda) ### Notes * Updates from the "fringes" * TUF for lawyers: been used in a couple of district * Need very long-term validation and verification of data * TAPs on a hash chain of old snapshot metadata * What do you do if you're worried about your cryptographic algorithms becoming invalid in the future? * Or some of the keys were generated badly, or... * Point of TUF: assume that servers/keys could be compromised * How would you extend that design if the *crypto itself* might become bad? * Why doesn't normal TUF cover this? * Some things should be confidential/encrypted! Those might become public later * Or you're worried about attesting to the evolution of the repository * Or if your hashing algorithm becomes compromised * Justin is thinking about this; still "early days" * Imagine 25 years ago * You only had MD5 and SHA1 * So even if you decided to pay 2x the cost by diversifying, you wouldn't have a "strong" algorithm today * If you assume everything will be badly broken in the future, you're somewhat limited * Need to think through transition * go-tuf * Sigstore interested in "general availability" * Need to speed up reviews etc. for go-tuf * Key encodings * Some implementations do hex, some do PEM * No standards for ECDSA/EDDSA * Should encodings be part of the public key parameters? * Same question for other things, like salt details * Putting them directly in the string name of the scheme is clunky, * But if you have a full schema you wind up in trouble: some algorithms don't use all of the fields, ambiguity in decoding. * You also often wind-up using one field for multiple purposes * "Someone" needs to sit down and disambiguate * Can we eliminate these concerns by forcing *one* key type in an ecosystem? * Trouble: we need to support lots of devices like HSMs, which may not support multiple formats * String names need to unambiguously refer to a set of parameters (including encoding, salt lengths, etc.) * AI: PR to the spec to clarify? <-- Trishank * PEP 458 updates? * Worth trying to see if we can help push this along * Design doc incoming * They're using python-tuf 2.0 (with succinct hashed bin delegation) * Problem in the last iteration: review took a really long time * There hasn't been a comprehensive review yet * Donald Stufft has volunteered to review it ## July 27, 2022 Meeting ### Agenda * Project updates * Introductions * POUF format questions (Aditya) * request for some TAP reviews (Marina) * friends of go-tuf (Trishank) * Marina: can you pls discuss on our behalf? Thx! * Sigstore as a super root (Zach) * CNCF Supply Chain Survey ### Notes ### Attendees * Lois Anne DeLong (NYU) * Marina Moore (NYU) * Aditya Sirish (NYU) * Joshua Lock (VMware) * Martin Vrachev (VMware) * David Strauss (Pantheon/Drupal) * Sebastien Awwad (Anaconda) * Abhisman (GSoC) #### Regrets/conflicts * Trishank Karthik Kuppusamy (Datadog) #### Project Updates * Sigstore is [documenting its TUF client](https://docs.google.com/document/d/1QWBvpwYxOy9njAmd8vpizNQpPti9rd5ugVhji0r3T4c/edit#) to enable validation of implementations and new implementations outside of the current Go library. * Uptane held a "community forum" in the Detroit area on June 17 which helped to prioritize short-term actions. Currently, a planning team is putting together a virtual workshop, to be held in collaboration with escar Europe, for October 13. The target audience will be OEMs and suppliers in Europe. * Python-TUF See pull request https://github.com/theupdateframework/python-tuf/pull/2000 * Go-TUF had a fix for Windows implementation and now tests on Windows as part of the CI suite. * PHP TUF-Had a question of how he should be keeping the community abreast of progress on the project. He is currently pushing to make PHP TUF work for Drupal. * To work on developing test suites for conformance testing do we need expertise from maintainers of different implementations or can we extrapolate input from just one implementation? * There is a difference, though, between conformance testing and interoperability testing. #### POUF format questions (Aditya) * Checking to see if there were any objections to extending the use of POUF formats * This would enable different implementations of TUF to work together if they elect to do so * https://github.com/theupdateframework/taps/blob/master/tap11.md #### Request for some TAP reviews (Marina) * Is there a way to make the review process more efficient? * Perhaps set aside a block of time to only review TAPs? * Maybe we need to work on developing better Pull Requests for these reviews. If they lack context and clarity, it discourages review. #### Sigstore as a super root (Zach) * Looking at a Sigstore plus TUF implementation; May actually want several variations on this model depending on how much one wants to use from each service. * "Federated TUF Model"--Eliminates the need to have a large initial TUF setup for each software distribution. * See initial draft of this idea at https://docs.google.com/document/d/1WPOXLMV1ASQryTRZJbdg3wWRR4ckK558kUnxn7Eixaw/edit?pli=1# * The proposal is modeled after OCSP stapling for delegation to remove the root from fielding requests from TUF clients ("Double TUF," perhaps mirroring the upper TUF repo) * Possibly set up a separate meeting or even a hackathon to address these issues. #### Friends of go-tuf (Trishank) * Trishank is looking to put together a team to offer better support to the go-tuf implementation #### CNCF Supply Chain Survey * Look for maintainers of TUF implementations willing to take a brief 20 minute survey. * Touch base with Marina if you are interested #### Miscellanous * Aditya is looking for a review on a PR that provide a way to "verifiably track back from the latest metadata and examine all previous legitimate versions of Snapshot metadata." * https://github.com/theupdateframework/taps/pull/157 ## June 22, 2022 Meeting ### Agenda * Project updates * Introductions * Merkle DAG TAP (Aditya) * https://github.com/theupdateframework/taps/pull/156 ### Attendees * Lois Anne DeLong (NYU) * Trishank Kuppusamy (Datadog) * Lukas Pühringer (NYU) * Marina Moore (NYU) * Joshua Lock (VMWare) * Aditya Sirish (NYU) * Martin Vrachev (VMware) * Nisha Kumar (Oracle) * Abhisman (GSOC) ### Notes #### Project Updates * Uptane held a Community Forum on 6/17. * Uptane also released a [whitepaper about Scudo](https://uptane.github.io/papers/scudo-whitepaper.pdf), which integrates in-toto into Uptane to protect the supply chain * Recent review of Go-TUF revealed a need for updates. A [security advisory](https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-66x3-6cw3-v5gj) was released telling users to update. * python-tuf has merged an implementation of [TAP 15](https://github.com/theupdateframework/taps/blob/master/tap15.md) that supports succinct hash bin delegations #### Merkle DAG TAP https://github.com/theupdateframework/taps/pull/156 * Merkle DAG TAP was inspired by conversations with [The Archive Framework (TAF)](https://github.com/openlawlibrary/taf) and folks working on Cabal, which already uses (an old version of) TUF, that want to switch to IPFS. * Comment--"Someone actually has done this in the automotive space, especially with OSTree. And, Google does it with Fuchsia too" * Question---"Can TUF support logical representations other than files?" This question comes from discussions at SPDX meetings. Also a number of discussions on the OCI Reference Types Working Group. (see https://github.com/opencontainers/wg-reference-types) * TUF itself is agnostic to the type of files, as long as there is a representation that can be identified and hashed. * ITE 4 of in-toto addresses a similar issue. However, with the Merkle DAG TAP, the items in question would not be controlled by TUF. (https://github.com/in-toto/ITE/blob/master/ITE/4/README.adoc) * A request was made to add a description to the current PR for this issue with an overview of the TAP,its current status, and the type of feedback requested. #### Other Business * Lukas noted that a proposal submitted on the Warehouse repository has been languishing without comments. (https://github.com/pypa/warehouse/pull/10870#issuecomment-1059177359) He is going to submit a briefer, more focused version of the proposal (see below). * The [Playground repository](https://github.com/jku/repository-playground) is an attempt to make PEP 480 more feasible to implement. The goal is to offer a complete reference implementation of PEP 480 that is less complex because it removes some of the repository limitations. * Do we need to discuss this with the Warehouse maintainers? Perhaps when the Playground PR is reviewed, it will spur some action, including possible meetings with the maintainers. * GSOC students are currently working on TAP 14 (https://github.com/theupdateframework/taps/blob/master/tap14.md) and TAP 17 (https://github.com/theupdateframework/taps/blob/master/tap17.md). ## April 27, 2022 Meeting ### Agenda * Project updates * Request for comments/review * [Update metadata version comparison rules in client workflow #209](https://github.com/theupdateframework/specification/pull/209) * [TAP 12 Acceptance](https://github.com/theupdateframework/taps/pull/152) * [TAP 15 Implementation Discussion](https://github.com/theupdateframework/python-tuf/issues/1943#issuecomment-1110672615) * go-tuf maintainer policy ### Attendees * Lois Anne DeLong (NYU) * Marina Moore (NYU) * Nisha Kumar (Oracle) * Radoslav Dimitrov (VMware) * Lukas Pühringer (NYU) * Abhisman * Martin Vrachev (VMWare) * Sebastien Awwad (Anaconda) ### Notes #### Project updates * New version of Python-TUF released today. * First time the release was handled "automatically" * Source and binary distributions are now reproducible thanks to the use of a new build tool [`hatchling`](https://ofek.dev/hatch/latest/build/#packaging-ecosystem) * Differences in status between Go-TUF or Python TUF was explained * Uptane has a new whitepaper, which will hopefully be released soon. #### Request for comments/review ##### [Update metadata version comparison rules in client workflow #209](https://github.com/theupdateframework/specification/pull/209) * The PR attempts to set a protocol for when metadata files should be updated roles vary in when this needs to be done. ###### [TAP 12 Acceptance](https://github.com/theupdateframework/taps/pull/152) * This PR formally proposes accept TAP 12 as approved. Action on this PR is requested. ##### [TAP 15 Implementation Discussion](https://github.com/theupdateframework/python-tuf/issues/1943#issuecomment-1110672615) * Lukas' proposal makes the case for considering the succinct hash delegation as an object unto itself. * The PR addresses in part any potential confusion between the use of the terms roles and delegations. * Sebastien provided the following definitions for the roles/delegations described here: * normal delegations: maybe every package in the repository whose name starts with "django/" is something you want to delegate to django team. * hashed bin delegations: in order to shard out a huge collection of targets space so they're not all listed in the same file, you split one targets file into a bunch of them, divided by the beginning of their hashes * More information on hashed bin delegations available here https://github.com/theupdateframework/python-tuf/blob/develop/examples/repo_example/hashed_bin_delegation.py * TAP 15 adds new fields that give hash bin delegations a distinct identity * Will this issue affect backwards compatibility? * There might be a need to explicitly prioritize normal over hashed delegations * The issue of order needs to be addressed before TAP 15 moves forward. #### go-tuf maintainer policy * There is a need to develop a policy for getting PRs merged. Since there were no go-tuf people in attendance, this was deferred. ## March 23, 2022 Meeting ### Agenda * Project updates * go-tuf - Zack has a bunch of commits on a [branch](https://github.com/znewman01/go-tuf/commit/b22d336a622c139d48e339ad1a035b6aeae1841a) with fun experiments. Would we want to merge any (after cleanup)? - (maybe, there are potential risks here) [`tuf-client`](https://github.com/znewman01/go-tuf/commit/b22d336a622c139d48e339ad1a035b6aeae1841a) file store (before, local testing required `python -m http.server`) - (follow python-tuf here) [`tuf import-key`](https://github.com/znewman01/go-tuf/commit/ddf69ff39866037d127b6678d1bc459c970a33ba) in `tuf` repo tool for ECDSA - (follow python-tuf here) extracting ECDSA keys in clients - (yes, but be careful--logic is tricky) clients can query [to what roles a target has been delegated](https://github.com/znewman01/go-tuf/commit/ebf60ea4af519c7282b9593dc7b2856fd4236235) (`tuf-client who-can-sign`) - (no, prefer Ethan's branch) [`tuf delegate --role=<role> --name=<name> --threshold=<threshold> [<path>...]`](https://github.com/znewman01/go-tuf/commit/3a7c96c395d1c6bc5ca1e5cfa24100736ac8a415) (only supports 1 level of delegation; probably worse than what Ethan's doing) - (no, wait until TAP accepted and prefer Asra's implementaiton)[sigstore delegations](https://github.com/znewman01/go-tuf/commit/895c5650ed2544e401737c64cfc3ed62dd0b90cf) - (no) [`tuf-client init --tofu`](https://github.com/znewman01/go-tuf/commit/0524c7962b5dcf8858cecb440faac45a1685dfe6) - (no) also nixos support but I know you don't want that ### Attendees * Lois Anne DeLong (NYU) * Justin Cappos (NYU) * Marina Moore (NYU) * Dan Meador (Anaconda) * Zachary Newman (Chainguard) * Sebasiten Awwad (Conda) * Trishank Kuppusamy (Datadog) * Lukas Puhringer (NYU) ### Notes #### Project Updates * Uptane released V.2.0.0 of its Standard for Design and Implementation last week. * Uptane will hold its first in-person workshop since 2019 in June of this year, in connection with escar USA. * The Python-tuf 1.0 release was issued. Working now on PyPi integration ([pypa/warehouse#10870](https://github.com/pypa/warehouse/pull/10870)). He noted that with this release, work on the release may be slowing down as more focus is placed on using the release. * Lukas will be presenting at Kubecon Europe this May, along with Jussi Kukkonen of VMware. The topic will be "Updates from the TUF Framework" ##### go-tuf * Zachary Newman has made a number of local commits which he reviewed and summarized. The group was asked to comment and decide on possible merges. * - [ ] [`tuf-client`](https://github.com/znewman01/go-tuf/commit/b22d336a622c139d48e339ad1a035b6aeae1841a) adds a file remote store (before, local testing required `python -m http.server`) * Justin urged some caution in moving forward until the issue is better understood * - [ ] [`tuf import-key`](https://github.com/znewman01/go-tuf/commit/ddf69ff39866037d127b6678d1bc459c970a33ba) in `tuf` repo tool for ECDSA * It was suggested that Zachary review the way this is addressed in Python-tuf - see [`securesystemslib`](https://github.com/secure-systems-lab/securesystemslib) - for pkcs11 see [python-tuf#1912](https://github.com/theupdateframework/python-tuf/issues/1912) (feature request) and [securesystemslib#229](https://github.com/secure-systems-lab/securesystemslib/pull/229) (ground work) * - [ ] extracting ECDSA keys in clients - [ ] clients can query [to what roles a target has been delegated](https://github.com/znewman01/go-tuf/commit/ebf60ea4af519c7282b9593dc7b2856fd4236235) (`tuf-client who-can-sign`) - [ ] * (https://github.com/znewman01/go-tuf/commit/3a7c96c395d1c6bc5ca1e5cfa24100736ac8a415) (only supports 1 level of delegation; probably worse than what Ethan's doing) * [ ] [sigstore delegations](https://github.com/znewman01/go-* - [ ] * tuf/commit/895c5650ed2544e401737c64cfc3ed62dd0b90cf) (worse than what Asra's doing) - [ ] [`tuf-client init --tofu`](https://github.com/znewman01/go-tuf/commit/0524c7962b5dcf8858cecb440faac45a1685dfe6) #### Other Business * Marina described some of the papers she is currently working on and asked for input/data if possible. These include: * A paper in the early stages of development that focuses on "multiple approaches that use authenticated data structures to more efficiently store revision information, while maintaining snapshot protection across all packages on a repository." She would welcome package upload and download logs from real-world repositories. * TAP 8--https://github.com/theupdateframework/taps/blob/master/tap8.md. Marina would like to hear about real world scalability use cases where this TAP—which allows a role to change or revoke keys without requiring changes from any parties that delegate to that role—might apply * Marina also discussed the Trident paper, which permits users in multirepository setting to articulate not only what repositories it trusts, but also what packages and developers it trusts. ## February 23, 2022 Meeting ### Agenda * [KubeCon EU project pavillion or in-person project meeting](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/project-benefits/) * go-tuf initial release * python-tuf 1.0! ### Attendees * Lois Anne DeLong (NYU) * Radoslav Dimitrov (VMware) * Trishank Kuppusamy (Datadog) * Marina Moore (NYU) * Sebastien Awwad (Conda) * Jussi Kukkonen (VMware) * Yaacov Finkelman () * Nisha Kumar (VMware) * Ivana Yovcheva (VMware) ) ### Notes Yaacov Finkelman and Nisha Kumar, both first time visitors, introduced themselves. Yaacov is working on "improving the Rust ecosystem." He invites feedback on his current PR https://github.com/rust-lang/rfcs/pull/3231. #### Project Round-up * Uptane approved the release of V.2.0.0 of its Standard and Deployment best practices. Versions in HTML and PDF should be available in a few weeks. * Uptane also submitted three projects for Google Summer of Code, including one for a re-design of its website. #### KubeCon EU project pavillion or in-person project meeting (https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/project-benefits/) * Will there be enough people in attendance to have a formal TUF presence there? * If there were TUF people present, perhaps there could be an informal TUF community meeting on-site. * Deadline to do something as part of the conference program is this week. Since few in the meeting had definite plans to be there, the consensus was that perhaps any who attend could do something unofficial this time around, (i.e. a dinner) rather than setting up something formally through the conference. #### Go-Tuf initial release * There is a PR at https://github.com/theupdateframework/go-tuf/pull/215 that lists a few of the remaining issues to be resolved. * An off-line meeting between Trishank and Radoslav Dimitrov will be scheduled to resolve some of the remaining problems. They plan to put together a checklist of what remains to be done so issues can be resolved methodically. #### Python-TUF 1.0 release * The release has been finalized and announced. See the release announcement at https://ssl.engineering.nyu.edu/blog/2022-02-21-tuf-1_0_0. #### OpenSSF Working Group * Trishank reported on a new working group that builds common supply chain security solutions for community repos like PyPI, RubyGems, npm, Crates, etc. See https://github.com/ossf/tac/issues/79. #### Miscellanous * Can TUF move away from being "file-centric"? This was briefly discussed in connection with Nisha's current work. https://docs.google.com/document/d/1SVOWQTowigXzbYdorzfa7tMmrcm91yK12LvSONqziJY/edit#heading=h.xzjuckal2b2a #### TAP 13 * A pull request regarding interactions with TAP 4 have been posted at https://github.com/theupdateframework/taps/pull/149. * Reviews are needed on this before the TAP can be approved ## January 26, 2022 Meeting ### Agenda * TAP status update * [pr to accept TAP 15](https://github.com/theupdateframework/taps/pull/148) * [TAP 13](https://github.com/theupdateframework/taps/issues/137) * Revisiting the [TUF roadmap](https://hackmd.io/zlm4OQ1ZQsidIRDqGAQ_xQ) ### Attendees * Lois Anne DeLong (NYU) * Marina Moore (NYU) * Lukas Pühringer (NYU) * Joshua Lock (VMware) * Radoslav Dimitrov (VMware) * Sebastien Awwad (Anaconda) * Cedric Van Rompay (Datadog) * Hossein Siadati (Datadog) * Ethan Lowman (Datadog) ### Notes #### Project Round-up * Uptane is preparing to release V. 2.0.0 most likely in early February * Uptane is also planning a series of workshops for 2022, both virtual and in-person (the latter in June after escar US) * python-tuf 1.0 real soon now (Feb?) * rust-tuf moved into theupdateframework organisation and is being actively maintained by Googlers working on Fuchsia * Lukas is making changes on the TUF GitHub organization permission model so touch base with him if this affects any implementations #### TAP Status Update ##### TAP 15 (https://github.com/theupdateframework/taps/pull/148) * Addresses succinct hash bin delegations * There is a proposal to move the PR to accepted * A question was raised about whether guidance was provided in the TAP about backwards compatibility. It could be an issue if a repository makes a change but its the clients do not. * Marina will follow up on Trishank's request (on the discussion thread) about the hashing algorithm. He questioned both the choice of SHA2-256, and why it was being applied only to fixing keyids. * The main concern is that the algorithm not be broken * It was pointed out that TAP 15 is not yet in the specification, so on that grounds, can it be accepted? * Decision was to hold off on accepting the TAP until at the very least a PR to include this feature has been added to the specification. ##### TAP 4 * In part because of its interactions with TAP 13 the question was asked if TUF 4 had an implemetation It is present in Uptane in two places: https://github.com/awwad/tuf (Uptane's implementation in a TUF fork; this has been used) and https://github.com/theupdateframework/python-tuf/pull/504 (an older client implementation) ##### TAP 13 (https://github.com/theupdateframework/taps/issues/137) * Biggest roadblock to acceptance is its interaction with TAP 4. * Needs a proof of concept * It's adoption could also be significant in Notary * Marina will look implementating this TAP in Go-TUF, but TAP 4 has not yet been implemented there and TAP 13 has a dependency on TAP 4. * Joshua suggested that an implementation in Python-TUF might be do-able. #### Revisiting the TUF Roadmap * Timeline as set in the roadmap called for implementations of TAP 3 & 4 this year. * It was suggested we do a minor release to introduce these TAPs. However, TAP 3 is not backwards compatible and should be moved to a major release (2.0.0) * Revising TAP 15 would be useful in the work on Warehouse * See the Roadmap document for revisions in the timeline (https://hackmd.io/zlm4OQ1ZQsidIRDqGAQ_xQ) ## December 15, 2021 Meeting ### Agenda * TAP review draft -> accepted? * [TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata](https://github.com/theupdateframework/taps/blob/master/tap13.md) * [TAP 15: Succinct hashed bin delegations](https://github.com/theupdateframework/taps/blob/master/tap15.md) * [TAP 16: Snapshot Merkle trees](https://github.com/theupdateframework/taps/blob/master/tap16.md) * request for general feedback, wait on acceptance until RSA acc work is finished * [asraa] Verification of expired targets (for example, a frozen transparency log's keys). Design [here](https://docs.google.com/document/d/1jIE44Fw7CVr0dLLwK9pYgNCIkzdCCeIUVuwgr0HRa8E/edit#) * [rdimitrov] go-tuf client workflow analysis * [ethan] Delegation progress on go-tuf * [hossein] Adding partial verification to the go-tuf? (git discussion: https://github.com/theupdateframework/go-tuf/discussions/187) * [ethan] Releases & versioning of go-tuf ### Attendees * Ethan Lowman (Datadog) * Hossein Siadati (Datadog) * Marina Moore (NYU) * Radoslav Dimitrov (VMware) * Lois Anne DeLong (NYU) * Asra Ali (Google) * Axel Simon (Red hat) ### Minutes #### TAP Drafts--Review for Possible Approval * Marina reported on the status of the Fulcio TAP, which is a WIP available at https://github.com/theupdateframework/go-tuf/pull/181/files. ##### TAP 13 (https://github.com/theupdateframework/taps/blob/master/tap13.md) * This TAP would allow the user to designate its top level Targets, so "different users of the same repository may elect to use different, repository-hosted, top-level targets metadata." It enables the client to determine who it trusts and who it does not. One of its changes is to delegate to role names, rather than file names. * Joshua Lock (who could not attend today) had recommended resolving a few more issues before acceptance. * One such issue is how does it interacts with TAP 4 (Multiple repository consensus on entrusted targets https://github.com/theupdateframework/taps/blob/master/tap4.md) * Decision was to defer approval till at least the January meeting to allow for resolution of the TAP 4 issue ##### TAP 15 and 16 * [TAP 15: Succinct hashed bin delegations](https://github.com/theupdateframework/taps/blob/master/tap15.md) * Currently no outstanding questions on this issue, though it could potentially be a breaking change if a user implements it. However, since this change is optional, that should not prevent adoption. * Would be good to move this forward as several implementations are pending * The TAPwas approved and Marina Moore agreed to submit a PR calling for it to be merged. * [TAP 16: Snapshot Merkle trees](https://github.com/theupdateframework/taps/blob/master/tap16.md) * Decided to hold off on an approval vote. #### Verification of Expired Targets (https://docs.google.com/document/d/1jIE44Fw7CVr0dLLwK9pYgNCIkzdCCeIUVuwgr0HRa8E/edit#) * The above proposal supports a way to account for certificates once they expire. This is problematic for artifacts that are not periodically rebuilt or resigned, or for products using a fixed, old version of an artifact. These expired certificates can not be verified under existing policies. * The link above is to a Google document where the issue is explained in full. Reviews and comments are welcomed. #### go-tuf workflow analysis * #### Delegation processes * Divided a very large PR into a number of smaller ones * Biggest piece of missing code for 1.0.0 status #### Adding partial verification to GoTUF * Borrowing from the Uptane model * Biggest challenge is that partial verification still needs to do some TUF checks * Need to make it clear that this can only be permitted where full verification is being done somewhere else (i.e. out of band) * Input may be needed from Justin or others #### Releasing and versioning of GoTUF * Still pre 1.0.0., but some type of versioning label may be required to alert users to breaking changes * Use commit messages? * Could use a changelog that adds release notes * A PR review checklist would be helpful before releasing * Check GoReleaser (https: as another way to handle versioning ## November 17, 2021 Meeting ### Agenda * Project/subproject Updates * Uptane * 2.0 upcoming (feedback welcome) * supply chain security whitepaper * [Signature wrapper TAP](https://github.com/theupdateframework/taps/pull/138) (Aditya) ### Attendees * Aditya Sirish (NYU) * Justin Cappos (NYU) * Lois Anne DeLong (NYU) * Ethan Lowman (Datadog) * Trishank Karthik Kuppusamy (Datadog) * Sebastien Awwad (Conda) * Kairo Francisco de Araujo (VMware) * Marina Moore (NYU) * Axel Simon (Red Hat) * Hossein Siadati (Datadog) * ### Minutes #### Project/Subproject Updates * Uptane will release V.2.0.0 in early 2021 * It will also be releasing a new whitepaper on supply chain security * Ethan Lowman has been added as a maintainer on Go-TUF #### Status of Signature Wrapper TAP https://github.com/theupdateframework/taps/pull/138 * TAP separates the signing mechanism from in-toto. * Introduces a new signing envelope-DSSE (Dead Simple Signing Envelope). The TAP does not specify the use of DSSE, but rather sets properties for such a signing envelope * in-toto has proposed a similar effort in ITE 5. * It was recommended that the authors examine other signing specification before finalizing the TAP. * Next step-implementation into a project, perhaps Go-TUF * There are no blockers on merging this TAP as a draft. Discussion will however continue on the issue thread. #### Review Status of other TAPs * TAP 13, 15 and 16 do have complete reference implementations and so meet the basic criteria for acceptance. All three TAPs will be discussed further at the next community meeting, and possible actions may be taken. * In terms of blockers, a format was proposed for TAP 13 in the reference implementation, butit not yet been accepted. * TAP 16-we need to better understand the pros and cons of this work before any decisions should be made * TAP 1 should be changed to better specify the general workflow of TAPs * Recommendation that each TAP should have a champion. #### Other Business * Marina noted she is working on a variant of TUF for registries for the Notary project. https://github.com/notaryproject/tuf * Justin reported that he is talking with attorneys about developing some form of verification for when and how code is changed. He will update us on this project at a future meeting. * Next meeting will be December 15. Note this is one week earlier than the normal meeting cadence because of the holidays. ## October 27, 2021 Meeting ### Agenda * Project/subproject news * Scaling snapshots research + ask (Marina) * Available real data (performance metrics) on TUF/UPTANE * Holidays and meeting time * Proposal: Nov 24 -> Nov 17, Dec 22 -> Dec 15 * Discussion of TUF CVE ### Attendees * Trishank Kuppusamy (Datadog) * Hossein Siadati (Datadog) * Sebastien Awwad (Conda) * Marina Moore (NYU) * Aditya Sirish (NYU) * D. Niu (Datadog) * Jussi Kukkonen (VMware) * Radoslav Dimitrov (VMware) * Teodora Sechkova (VMware) * Pradeep Srinivas * Martin Vrachev * Lois A DeLong * axel simon (red hat) * Parvesh Katoch ### Minutes #### Scaling Snapshot research * Marina Moore shared some information and requested feedback on the work so far * This focuses on how much data is collected during uploads and downloads * A form email exists describing exactlly what data is useful #### Adapting meeting schedule * November meeting will be moved forward to the 17th; December meeting to the 15th #### Discussion of the TUF recent CVE Advisory: https://github.com/theupdateframework/python-tuf/security/advisories/GHSA-wjw6-2cqr-j4qr * The CVE was "a path traversal vulnerability that in the worst case can overwrite files ending in .json anywhere on the client system on a call to get_one_valid_targetinfo(). It occurs because the rolename is used to form the filename, and may contain path traversal characters (ie ../../name.json)." * The vulnerability has been fixed in Rust TUF and python-tuf. * To be able to respond to incidents like this in the future, it would be good to have a protocol in place for responding to such vulnerabilities in the future, including who should be contacted * Action item: Develop this protocol. #### Other items * Pradeep Srinivas raised the following questions * How different is the OTA Community edition by HERE from the python reference implementation for uptane ? * Any idea on why the OTA CE was stopped ? * Is there any advantage on building a solution on top of OTA CE or can would you suggest we build our solution on top of python reference implementation ? * Pradeep was invited to attend the Uptane Standards meetings and to raise his questions within that community. * Trishank shared some highlights from a presentation on the "State of the Art of Supply Chain Security" that was delivered at Supply Chain Security Con. The presentation shows how adding transparent logs from Sigstore strengthens security by adding credibility to the signature. https://static.sched.com/hosted_files/supplychainsecurityconna21/9c/SupplyChainSecurityCon%202021_%20State%20of%20the%20art%20supply%20chain%20security.pdf * Marina noted that Joshua Lock and herself will be presenting at PackagingCon next month (https://pretalx.com/packagingcon-2021/talk/YRTFG9/). * Jussi noted that Python TUF has posted a new PR dealing with metadata API and asked for review and comment. ## September 22, 2021 Meeting ### Agenda * [TUF Roadmap discussion](https://hackmd.io/zlm4OQ1ZQsidIRDqGAQ_xQ) (Marina) * Repository automation with GitHub Actions (Jussi) * [live repo](https://github.com/jku/tuf-repo-test/) * [tool](https://github.com/vmware-labs/repository-editor-for-tuf/) * [PURE 2: Offline Updates](https://github.com/uptane/pures/pull/3/files) (Jon) ### Attendees * Trishank Kuppusamy (Datadog) * Joshua Lock (VMWare) * Aditya Sirish (NYU) * Marina Moore (NYU) * Jon Oster (Toradex) * Hossein Siadati (Datadog) * Ethan Lowman (Datadog) * Adrien Delsalle (QuantStack) * Jussi Kukkonen (VMware) * axel simon (Red Hat) * Lois Anne DeLong (NYU) * Sebastien Awwad (Conda) * Matt Rutkowski * Asra Ali (Google) * Pradeep Srinivas ### Minutes #### Introductions * Several new participants, including Jon Oster from Toradex, and Axel Simon from Red Hat were present and introduced themselves. #### TUF Roadmap https://hackmd.io/zlm4OQ1ZQsidIRDqGAQ_xQ * It's been awhile since the TUF project has had a roadmap. The link above is an attempt. * The list mostly focuses on clearing open TAPs. However, integrating TAPs often creates much more work than anticipated (see TAP 4) * We will continue to iterate on this roadmap with a specific focus on simplifying the client workflow * TAP 3 and 4 will be considered priorities for this year with a suggested January 2022 release * In moving forward, we seek to enhance readability but do so without creating any gaps in the implementation that can lead to mistakes * Maybe we need to clean up/clarify the current specification before adding more to it? * Semi-official implementations must correctly report the version of the spec they are implementing * Takeaway: First clean up the spec. Then get all implementations to be up to date to one specified version. #### Repository automation with GitHub Actions Live repo: https://github.com/jku/tuf-repo-test/ Tool: https://github.com/vmware-labs/repository-editor-for-tuf/ * Jussi presented a demo of the propsed repository editor * Offers a simple way to edit any repository to add roles, etc. to TUF * Not sure at this point of how this can be used in TUF, but there may be possibilities #### PURE 2: Offline Updates https://github.com/uptane/pures/pull/3/files * Jon started by highlighting how Uptane differs from TUF (second repository, difference in the way it addresses Targets) * There is some demand in the auto industry for offline updates. Some industrial control systems are also not connected to the internet and could use a more secure way to do updates. Other systems may need both OTA and offline updates. Either way, it would be desirable to be able to direct these offline updates to offer some degree of validation and protection for the update proces. * The idea of this PURE is to find a way to securely do Uptane updates through offline strategies. * The PURE would add a new role to the Director repository, called the "offline-update" role. It would be responsible for producing and signing metadata about sets of images that are valid for offline updates. This includes two types of metadata: offline-update snapshot metadata and offline-update targets metadata, which would be analagous to snapshot and targets metadata on the image repository. * This would require a different threat model and it would probably require different expiry times * Trishank observed that the idea is similar idea to one presented on the Mercury paper--"You just catch up with the trusted baseline" * One possible drawback might be that it would remove the ability to revoke? * Jon asked for feedback on the pull request, whih will also be discussed at our next Uptane meeting. ## August 25, 2021 Meeting ### Agenda * Project/subproject news * [Uptane workshop](https://www.escar.info/escar-europe/registration.html) * TUF/sigstore integration * Asra: [Add TUF metadata to Rekor](https://github.com/sigstore/rekor/pull/383) * Open PRs/issues/discussions/TAPS * specification * More than a few open PRs. How do we resolve them ASAP? * TAPS * Marina: [TAP for use of Fulcio delegations](https://github.com/theupdateframework/taps/pull/141) * go-tuf * Asra: [[types] add custom json message to keyval](https://github.com/theupdateframework/go-tuf/pull/133) * Asra: [Generalize "keyval" data to be any custom JSON containing public portion of key](https://github.com/theupdateframework/go-tuf/pull/141) * Hossein: [root rotation](https://github.com/theupdateframework/go-tuf/pull/143) * Ethan: [Move delegations iterator to internal package](https://github.com/theupdateframework/go-tuf/pull/144) * Trishank: adding more reviewers (Hossein/Ethan/Raphael)? * py-tuf * What is the primary purposes of [the Python reference implementation aka py-tuf](https://github.com/theupdateframework/tuf)? * a learning resource to aid understanding of the specification (pedagogical reference)? * a good architecture for other implementations to mimic (exemplary reference)? * Can we have a set of fixtures that every implementation can use to test? * Do we want to keep using the [TUF roadmap](https://github.com/theupdateframework/tuf/issues/1525)? * Can we close sufficiently stale issues/PRs? * Miscellaneous * Matt: can we leverage TUF deeper in things like Tekton? * Demos * Jussi: demo of repository automation with Github Actions using [tufrepo](https://github.com/vmware-labs/repository-editor-for-tuf/) (an experimental repository editor built with the new py-tuf Metadata API) * Marina: [RSA accumulators for scaling snapshot](https://github.com/theupdateframework/tuf/compare/develop...mnm678:snapshot-rsa-acc?expand=1) * snapshot gets large listing targets metadata files * First idea was TAP 16 -- snapshot merkle tree * Requires auditors to make sure version numbers do not go backwards (Mercury protection) * RSA accumulators are another way to represent the same idea. Similar to a Merkle tree, but easier to update and can _potentially/maybe_ be faster to do – do not need to compute hashes as in Merkle tree, it's multiplication and a single exponentiation operation * Very WIP implementation https://github.com/theupdateframework/tuf/pull/1510 * doesn't implement update or generate metadata yet * would love to see numbers compared to Merkle trees * to achieve Mercury level protection, requires external auditor/server implementation to verify the accumulator "tree" * External auditors help ensure you are seeing the same TUF repo as other clients ### Attendees * Marina Moore (NYU) * Aditya Sirish A Yelgundhalli (NYU) * Justin Cappos (NYU) * Martin Vrachev (VMware) * Jussi Kukkonen (VMware) * Teodora Sechkova (VMware) * Joshua Lock (VMware) * Ethan Lowman (Datadog) * Sylvain Baubeau (Datadog) * Raphael Gavache (Datadog) * D Niu (Datadog) * Hossein Siadati (Datadog) * Cem Gurkok (Datadog) * Trishank Karthik Kuppusamy (Datadog) * Matt Rutkowski (IBM) * Sebastien Awwad (Anaconda) * (Add yourself) ### Minutes * [Link to Uptane workshop](https://www.escar.info/escar-europe/registration.html) * Introductions * Open PRs/issues/discussions/TAPS * specification * Those who review/merge PRs should meet separately to knock this out. Marina to send Doodle/calender invite out? * TAPS * TAP PR for [Fulcio delegations](https://github.com/theupdateframework/taps/pull/141): need more eyes. Plan to merge it in a few weeks. * go-tuf * Let's make time to review the PRs * root rotation: a breaking change (not downloading root over basically TOFU). Hossein to reach out to [fleetdevicemanagement](https://github.com/fleetdm/) to get their input. * delegation iterator: small PR towards implementing writing delegations. * Reviewers: send a PR to run by the original maintainers, nominating Hossein/Ethan/Raphael. Clean up * py-tuf * Leaning towards being an exemplary architecture * Examples: [only one entry in timestamp, so why a dictionary](https://github.com/theupdateframework/tuf/issues/1443)? Uniquely recording delegations internally inside a Python dictionary instead of using the list from JSON. * Fixtures: there have been talks about sharing a universal repository. Hossein/Datadog can help start it. * Roadmap: doesn't belong in reference implementation. Also a lot of barrier if we put it in a code repository. Setting goals for TAPs and PRs would be helpful. We could edit a HackMD once a quarter during the community meeting. Let's start at the next meeting. * Closing stale issues/PRs: let's make it one of the first items for the ROADMAP in the next meeting. * Miscellaneous * Matt was missing, so maybe next time * Demos * Jussi's PR of tufrepo * Marina's discussion of [scaling snapshot with RSA accumulators](https://github.com/theupdateframework/tuf/pull/1510). First idea was [TAP 16: Merkle trees](https://github.com/theupdateframework/taps/issues/134). Idea with RSA accumulators is to also scale but with a different data structure. Similar to Merkle trees but easier and faster to update. Need to investigate pros/cons vs Merkle trees. Idea is to encode key-values as primes, then you exponentiate them to get a unique prime number, and then you can easily check whether any prime is a member. (Reminds me of Gödel encoding with the Fundamental Theorem of Arithmetic.) ## July 28, 2021 Meeting ### Agenda * License issues raised by Debian have been resolved, pending a release of securesystemslib * [securesystemslib#366](https://github.com/secure-systems-lab/securesystemslib/pull/366) * [tuf#1491](https://github.com/theupdateframework/tuf/issues/1491) * [TAP for use of Fulcio delegations](https://github.com/theupdateframework/taps/pull/141) ### Attendees * Hossein Siadati (Datadog) * Aditya Sirish (NYU) * Marina Moore (NYU) * Asra Ali (Google) * Sebastien Awwad (Anaconda) * Lois DeLong (NYU) * Jonathan Bushnell (Datadog) * Dan Lorenc (Google) * Teodora Sechkova (VMWare) * Joshua Lock (VMWare) ### Notes #### License issues raised by Debian * Was resolved before the meeting, so no discussion required. #### TAP for use of Fulcio delegations * Marina shared the TAP proposal for the use of Fulcio to improve developer key management in TUF. https://github.com/theupdateframework/taps/pull/141 * The TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. Targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification. * Provides a solution for key managers who can't or won't manage their own keys. It alows developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. * Implementation is still a work in progress * Question raised about what counts as uniqueness with Fulcio IDs. Can an email provide uniqueness as opposed to the ID? * Does the identity of the issuer tell you how to do the verification? And what can a malicious issuer actually do? * There is a need to trust the issuer out of band. #### TAP 12 https://github.com/theupdateframework/taps/blob/master/tap12.md * There were a few questions about the purpose of this TAP, which deals with improving keyid flexibility. #### Offline updates and Uptane news * An issue was introduced at a recent Uptane meeting about handling offline updates. Specifically, the concern was if Uptane can support updates that required a dealer or a qualified technician to perform updates manually, rather using over the air technology. * One participant commented it would be similar to using an untrusted local repository. * Is this an issue TUF wants to engage with? * The issue described above is the first proposed revision that will fall under Uptane's version of the TAP process. Labeled PURE for Proposed Uptane Revision and Enhancement, it borrows the general structure and format of TUF TAPs. PURE 1 can be found at https://github.com/uptane/pures/pull/1 and TUF community input is most welcome. * In other Uptane news: It released a whitepaper, which can be downloaded at https://uptane.github.io/papers/Uptane_first_whitepaper.pdf and will be hosting an online workshop in connection with escar Europe. The workshop is free and even though registration is through escar, there is no need to sign up for the escar conference. Registration link is at https://www.escar.info/escar-europe/registration.html #### TAP Issues * Aditya Sirish asked for input and comment on TAP-17 /POUF-1: Remove signature wrapper from TUF spec, and update reference implementation to use DSSE https://github.com/theupdateframework/taps/pull/138 * Overall status of TAPs...what needs to be done to move things forward? * Can TAP 4 be integrated in the specification? It would add some work for the implementer side. * Marina will look into revising/rewriting PR#150 which could move TAP 4 forward. ## June 23, 2021 Meeting ### Agenda * Introductions * Project/subproject news * [Uptane whitepaper](https://github.com/uptane/papers/blob/master/uptane-whitepaper.md) (Marina) * [Sigstore root key ceremony](https://www.twitch.tv/videos/1060206516) * [TAP 17 & changes to POUF 1](https://github.com/theupdateframework/taps/pull/138/) (Aditya) * [Sigstore/TUF demo](https://docs.google.com/presentation/d/156BzrEvoAcTfKdGCWn-iuHaXEn30ICO66UFSrxgmM2w/edit#slide=id.p) (Asra) * Debian RFC * Next meeting time: 7/28 ### Attendees * Marina Moore (NYU) * Trishank Kuppusamy (Datadog) * Aditya Sirish (NYU) * Sebastien Awwad (Anaconda) * Teodora Sechkova (VMWare) * Asra Ali (Google) * Ted Bowman (Drupal) * Jannis Lydell * Dan Lorenc (Google) ### Notes #### Project news ##### *Uptane* * Released its first whitepaper * Will be releasing V.1.2.0 of Uptane at the end of the month. #### SigStore Root Key Signing * Signing was held on June 18. #### TAP 17 * Aditya reported that TAP 17 has been updated to remove the discussion of the wrapper in the specification * Current PR (#138) looks to remove signature wrapper from TUF spec, and update reference implementation to use DSSE * https://github.com/theupdateframework/taps/pull/138 * Some discussion of whether this new TAP will be a breaking change * Marina pointed to TAP 14 https://github.com/theupdateframework/taps/blob/master/tap14.md #### CoSign and SigStore * Asra did a presentation on this topic, providing background and then conducting a demonstration. * One thread of discussion was using Fulcio OICD, which uses ephemeral keys * She also presented a demonstration of how the signing would work. * Marina suggested that Asra prepare a TAP for the OICD portion of the process. #### Debian RFC * There is some question of licensing issues with this. * Some historical issues--history appears to have been deleted. * https://app.slack.com/client/T08PSQ7BQ/C8NMD3QJ3/thread/C8NMD3QJ3-1624384442.076800 * https://github.com/theupdateframework/tuf/issues/263 * ask rzr in slack #### Other Business * Drupal is looking for someone to help with the server side * https://cloud-native.slack.com/archives/C8NMD3QJ3/p1624311544069400?thread_ts=1623777486.063200&cid=C8NMD3QJ3 ## May 26, 2021 Meeting ### Agenda * Project/subproject news? * Uptane 1.2 release and workshop * Python-tuf [next-gen client](https://github.com/theupdateframework/tuf/pull/1408) * [TAP Milestones](https://github.com/theupdateframework/taps/milestones) (Marina) * Next meeting time: 6/23 ### Attendees * Marina Moore (NYU) * Sebastien Awwad (Anaconda) * Joshua Lock (VMWare) * Trishank Kuppusamy (DataDog) * Teodora Sechkova (VMWare) * Philippe Coval (Debian) ### Notes #### Project/subproject news ##### Uptane * Uptane will be releasing 1.2.0 next month * Plans are proceeding for a virtual workshop for European/Asian OEMs and suppliers this fall ##### Python-tuf * Joshua updated the current status of ngclient: a new client library implementation. * Marina suggested that, if funding is available to do penetration testing on the new implementation ##### TAP Milestones * Marina put together a list of proposed milestones for current TAPs *https://github.com/theupdateframework/taps/milestones * Trishank asked if it might make more sense to post TAP publications alongside the specification in a separate repository in order to give them more visibility. ##### Other business * Sebastien announced the upcoming release of Anaconda content trust; the feature released a few weeks ago is specifically "conda package signature verification." https://www.anaconda.com/blog/conda-signature-verification. It protects individual signatures on packages traveling from repo to repo * Trishank pointed out that Fuchsia has been released * Trishank also talked about a CNAB security initiative that offers a method for installing images in a cloud agnostic way and uses TUF and in-toto * Marina reported developments in sigstore...will be integrating a number of TUF features. Suggestion was made to invite representatives for the the group at this meeting. * There was brief period of issue review and "squashing" for the specification ## April 28, 2021 Meeting ### Call information * Wednesday April 28 11am ET (8am PT, 3pm UTC) * meet.google.com/jhk-cvuf-icd ### Agenda * Project/subproject news? * [Bikeshed Formatted Spec](https://theupdateframework.github.io/specification/latest/) * php-tuf & its integrations * reference implementation refactor * removal of current "mirrors" implementation * Working with sigstore community * [Signing specification](https://github.com/secure-systems-lab/signing-spec) * Goals: * combine signing solutions for TUF & in-toto, maintained separately * solve some of the problems in the signature wrapper, i.e. canonicalisation * Proposal: open a TAP to discuss adopting signing-spec (Aditya) * [keyid dictionary proposal](https://github.com/theupdateframework/specification/issues/155) * draft branch/minor release (client-only changes?) * Should they be a release per TAP? or one TAP that includes all "minor" changes? * Multi-role delegations (TAP 3) * Spec is ~ready, release some time this year? 1.1 * Succinct HBD (TAP 15) * User Selection of the Top-Level Target Files Through Mapping Metadata (TAP 13) * Priority for Uptane. Backwards compatible, only requires client-side change. 1.2? * Snapshot Merkle Trees (TAP 16) * 2.0.0 specification roadmap? * TAP 14, 15, 16, 12, 8, 13 * Detached signature wrapper * [terminology pet peeves](https://github.com/theupdateframework/specification/issues/149) * Recurring meeting time * php-tuf folks are predominantly west coast * New attendees: Kainaat, Marcin, Phillipe ### Attendees * Aditya Sirish (NYU) * Marina Moore (NYU) * Trishank Kuppusamy (Datadog) * Justin Cappos (NYU) * Marcin Kustra (Motorola Solutions) * Kainaat Singh (University of Bonn) * Teodora Sechkova (VMWare) * Joshua Lock (VMWare) * Philippe Coval (Debian) * Jussi Kukkonen (VMWare) * Martin Vrachev (VMWare) #### Project/subproject news * Php-Tuf implementation is in the works * Question arose on the role of mirrors in the reference implementation. Should they still be mentioned? * Consensus seems to be that references to mirrors should be taken out #### Signing specification * The specification would combine signing solutions for TUF and in-toto * In-toto side of the issue is covered in ITE 5 https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc * Use case for TUF 2.0.0. https://github.com/secure-systems-lab/signing-spec/blob/master/background.md#design-requirements * The new spec does not trust the keyids. Wouldn't this issue still need to be dealt with? * Perhaps there is a need to open a TAP dealing with the signing solution so we can solicit feedback from the commmunity? #### Keyid Dictionary Proposal See above #### 2.0.0 Specification roadmap * There is a need to determine which current issues (TAPs) are truly breaking and, if so, establish a timeline to work towards that release. * Currently no issues have been designated specifically for this release and there is no timetable as yet. * There is currently a draft branch, but not for 2.0.0. * TAP 3 and 16 could be addressed in the minor release What else can go there? * For 2.0.0., TAP 8 and TAP 14 * Minor/patch releases can be issued one at a time or gathered together for release in a larger batch. It was suggested that patch releases can be issued whenever TAPs need to be added. * And added benefit of more patch release is that it could indicate the project is active and is getting things done. * Perhaps Tap 3 can be released as 1.1.0 and TAP 13 as 1.2.0 * Uptane is waiting for the release of TAP 13 so it can reference it as a source #### Setting a recurring meeting time * Current time is difficult time for West Coast participants, particularly for the PHP TUF people * However, if we give more notice, someone can likely attend. #### Other business * Philippe Coval presented a brief update on his work on the Debian Python implementation of TUF * https://salsa.debian.org/python-team/packages/tuf ## 11/9 Meeting ### Call information * 11am ET * meet.google.com/khm-jcww-vxm ### Agenda * Introductions and project updates * PEP 480 update * Documenting specification review expectations: https://github.com/theupdateframework/specification/issues/130 * Architectural Decision Records for the TUF reference implemenation: https://github.com/theupdateframework/tuf/pull/1182 * Ideas about the TAP process: https://github.com/theupdateframework/taps/issues/127 ### Attendees * Marina Moore (NYU) * Joshua Lock (VMware) * David Halls (HP) * Jussi Kukkonen (VMare) * Santiago Torres-Arias (Purdue University) * Tedora Sechkova (VMware) * Martin Vrachev (VMware) * Tim Lehnen (Drupal) * Lukas Pühringer (NYU) * Trishank Kuppusamy (DataDog) ### Notes * Introductions and project updates #### PEP 480 update Marina briefly update work on PEP 480 and shared the relevant links. * Documenting specification review expectations: https://github.com/theupdateframework/specification/issues/130 * Architectural Decision Records for the TUF reference implemenation: https://github.com/theupdateframework/tuf/pull/1182 * Ideas about the TAP process: https://github.com/theupdateframework/taps/issues/127 #### Documenting specification review expectations: https://github.com/theupdateframework/specification/issues/130 * Joshua Lock discussed the specification review expectation which now mandates at least a one week review period for approving any PR. * The PR above also included a recognized list of maintainers * Santiago asked if there was a way to automatically update this list of maintainers. * The latter may require some additional thoughts #### Architectural Decision Records for the TUF reference implemenation: https://github.com/theupdateframework/tuf/pull/1182 * This is motivated by refactor efforts for the TUF Reference Implementation, which is currently being rewritten. A Markdown file is being used to record all decisions that go into architectural AND wording changes so a complete transparent record is always available. * Link to the refactor efforts https://github.com/theupdateframework/tuf/projects #### Ideas about the TAP process: https://github.com/theupdateframework/taps/issues/127 * TAPs are currently written "fully formed," without any type of rationale to explain the decision-making behind the proposal. Alternative solutions that might have been considered are not addressed. * Where should this discussion be preserved? * Tim suggested that perhaps a separate document could be used to present this motivation. * Marina noted that perhaps this rationale could be included in the discussion section? * Santiago asked if more can be done to bring in the discussion that may occur on calls or at in-person sessions. * Lukas suggested creating a github label to mark where discussions on different TAPs occur * Overall decision....need for more documentation #### General Discussion * Securesystemslib used by TUF and in-toto has some architectural and metadata issues in key signing. Encryption of keys has been a particular issue. * Ended up creating a number of different interface issues * Temporary solution while dealing with the bigger issues of SSL * Lukas noted that perhaps securesystemslib should be looking to not have its own key encryption system (Lukas: Please verify this point) * Also related: https://github.com/secure-systems-lab/securesystemslib/milestones ## 10/20 Meeting ### Call information * 12pm ET * http://meet.google.com/vuz-bsjh-gkb ### Agenda * Introductions and brief project statuses * Update on the python-tuf refactor * discuss supporting pip integration with current implementation * [Signing Spec](https://github.com/secure-systems-lab/signing-spec/issues/1) * [Rewriting spec to factor out sub-sections](https://github.com/theupdateframework/specification/issues/121) * [Fixed notion of time for an update cycle](https://github.com/theupdateframework/specification/pull/118) * TAP updates * [Alternative licences for TAPs](https://github.com/theupdateframework/taps/issues/126) * TAP 5/13 * TAP 8 * Newcomer comments on TAP process and related SW development / Jussi * Setting up regular meetings: monthly? Bi-weekly? What time? ### Attendees * Aditya Sirish A Yelgundhalli (NYU) * David Strauss (Drupal) * Erick Tryzelaar (Google) * Jess (xjm) (Drupal) * Joshua Lock (VMware) * Jussi Kukkonen (VMware) * Lukas Pühringer (NYU) * Marina Moore (NYU) * Ted Bowman (Drupal) * Teodora Sechkova (VMware) * Trishank Kuppusamy (Datadog) ### Notes * python-tuf refactor * [refactor mostly in planning](https://github.com/theupdateframework/tuf/projects/2) * recommends pip work mostly with the current implementation * when do we expect the new implementation to be done? * estimating to be about a year * pip only needs the client, if that could be migrated first it could simplify things. * [signing spec](https://github.com/secure-systems-lab/signing-spec/issues/1) * enable TUF and in-toto specs to focus on how they works, rather than on the signatures and wrapper * beneficial to us to keep TUF and in-toto in sync. * [in-toto enhancement](https://github.com/in-toto/ITE/pull/13/files#diff-905cb7de3b98a8cd4409021f71d34d763774bed25d81a4be9d2699a4b5ae2847) * proposal avoids canonicalization and parsing pre verification * removs reliance on serializing to JSON - can handle arbitrary payloads * proposed by Mark Lodato of Google's Binary Authorization team * incorporated into early draft of new signing spec, open for discussion * ways to avoid canonicalization * php-tuf would like to avoid canonical-JSON as they do not have a canonicalisation implementation * Google security team likes CBOR – considering binary encoding that may use CBOR * rewriting spec to factor out subsections * Erick working on a backstop metadata TAP as well as adding to the spec a client trust initialisation sequence (like the update flow, but data is local) * The above changes would require a lot of copy/paste – which is prone to maintenance errors * Playing with porting to bikeshed, as used by the WHATWG – WIP @ https://erickt.github.io/tuf-specification/ * WHATWG specs also have a notion of referenceable sub-sections (i.e. url parser). The spec may benefit from similar sub-sections (i.e. signature verification, called from root verification twice 1. trusted metadata 2. new root) * What are next steps? * need some mechanism to publish to theupdateframework.io * Erick has wip branch with changes to support bikeshed * Fixed notion of time for the client workflow * Drupal captures a notion of "now" and have injected something into their TUF implementation * TAPS * Alternative licenses – Apache should work just fine * TAP 5/13 - This TAP is proposing adding support for additional client customization of trusted packages on a repository. TAP 13 has superceded TAP 5 for this purpose. * TAP 8 - pending a PoC, probably easier to do once the refactor is implemented. Nice to have to future. * Feedback on TAP process: * Reviewing TAPs hard * Typical open source process * File issue, root cause, discuss possible solutions * Pull request discusses actual implementation * TAP & PoC are both implementations of a solution - the discussion that leads to the solution is not attached to the TAP. That makes review harder if definition of problem and choice of solution is not attached. * Would help to have more of the early discussion in the open and attached to/referenceable from the TAP * Formalise a recommendation in TAP 1 to start the TAP process with a discussion * Enhance TAP 2 template to provide more context, set up problem and link to prior discussions * Rust recommends a problem statement document, before proposing an implementation, that generates consensus for the problem before work begins on a solution * Rust's [Collaborative summary documents](http://smallcultfollowing.com/babysteps/blog/2019/04/22/aic-collaborative-summary-documents/) * Other docs about rust's new processes: https://internals.rust-lang.org/t/aic-adventures-in-consensus/9843) * Human problem that being presented a solution makes it hard to question the problem being addressed * Jussi to file an issue against the TAPs repo * Future regular meetings * Being with monthly cadence * Start one hour earlier (11am EDT) * Tuesdays & Thursdays * tentatively plan for next meeting mid November ## 5/27 Meeting ### Call information * 10am ET * https://meet.jit.si/TUFCommunityMeeting ### Agenda * File system abstractions: https://github.com/theupdateframework/tuf/pull/1024 * Canonical json and specification flexibility * Should the specification recommend a wireline format? * For background: [Joshua's email about this topic](https://groups.google.com/d/msgid/theupdateframework/f353602d-a9a6-4808-8328-c7dcc6c72fb5%40googlegroups.com.), [TAP 11](https://github.com/theupdateframework/taps/blob/master/tap11.md) * Warehouse (PyPI) rollout timeline * updating https://github.com/pypa/warehouse/issues/5247 with a checklist * WIP PR: https://github.com/pypa/warehouse/pull/7488 * Reference implementation refactor ### Attendees * Marina Moore (NYU) * William Woodruff (Trail of Bits) * Joshua Lock (VMware) * Teodora Sechkova (VMware) * Trishank Karthik Kuppusamy (Datadog) * Lukas Pühringer (NYU) * Lois Anne DeLong (NYU) * Justin Cappos * Jesús Castro * Pranshu Bajpai * Aditya Sirish A Y (NYU) * Martin Vrachev (VMware) ### Notes * TUF, via securesystemslib, now supports "abstract" files and directories – enabling pluggable integration with non-local storage. Was implemented to support Warehouse integration, but may be useful for other users? * Canonical JSON * How to gather feedback from existing adopters/implementers? * Marina to file an issue against the spec on GitHub and tag implementers * Mid-to-late June should see a fully-working test production implementation of TUF & Warehouse * Remaining items: * Pyramid-style service interfaces for the abstract FS in TUF/securesystemslib * Changes to the upload endpoint to facilitate target creation * Event plumbing * Rollout plan: test.pypi.org, then pypi.org * python-tuf code refactor. Lot of interest and a lot of issues. * Large sub-topic: metdata representation – at least 3 ways to represent TUF metadata in the current implementation (class-based in repository_tool, roledb, on-disk JSON representation). No reason to have all three and should result in simpler code if we consolidate. * https://github.com/theupdateframework/tuf/issues/1005 * https://github.com/theupdateframework/tuf/pull/868 * https://github.com/theupdateframework/tuf/pull/846 * Volunteers are needed to work on this. Joshua offered to help. * Set up a separate meeting to address this issue. Could a meeting be scheduled in the next two weeks? * What to do about in-process TAPs? Can these be moved to acceptance. * There are a number of open draft TAPs, so these should be revisited. * TAP 5 and TAP 8 are top priorities. TAP 5 requires resolution first. * There is general agreement that TAP 8 should be merged, but more discussion may be required. * TAP 3 is not implemented, but has a PR pending. It has been implemented in Uptane, but not in TUF * Should we do a Pull Request that accepts all drafts for V. 2.0? * Marina to review PR 57 * May need a dedicated meeting to discuss PR 86 (Trishank to schedule) * Make a plan for which TAPs are relevant to which versions. * What about TAP 5? (Setting URLs for roles in the root metadata file). Homework for the next meeting, so that we can discuss there. Will be needed for Notary V.2. Was initially written for use with CoreOS, so perhaps bring them into the discussion. * https://github.com/theupdateframework/taps/blob/master/tap5.md * https://github.com/theupdateframework/taps/issues/34 * Need to dig out the Trident paper? (Lois can provide this) * Notary design proposal includes options to adjust for scalability * Instead of writing snapshot and having people download it every time, generate a Merkle tree and have them download the patch of the tree for the specific project they are downloading. This is a workaround for scaling snapshot, but has downsides as described in the document * This model also gives rollback protection on first download, whereas they are usually only available on subsequent downloads * Makes initial download much cheaper and large metadata amortised over time * Could be a future TAP, but requires more examination. It offers two options and so we would need to decide if compliance requires both. * https://docs.google.com/document/d/1w8PFELVxt4p1aMk5oJv0RbDyd5J4OyvwguNSNZ1sJNw/edit?ts=5ec03e3b&pli=1# * Warehouse meeting scheduled for Friday (6/5) * Separate meeting needed for TAP 5? Notary V2 decision needs to be made in about 10 days. A draft proposal is needed before next Monday (6/1) * Next General meeting: June 24 in the 10-12 EST range

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.