TAP-21 update: Christopher will gather and share more data. Expects to connect with some folks from Packagist at an upcoming conference. No other work on TAP-21 is planned for the time-being, mostly due to lack of time to focus on it.
Discussion came up in go-tuf to handle HTTP 403 and 404 differently, currently behavior matches python-tuf but reporting them equally should be changed
Should "recommended hash algorithms" be documented somewhere (TAP?) or should we just add algorithms like blake2b to tuf-conformance test suite and wait for feedback/results?
AI: Implement in go-tuf the same way it was done in python-tuf (make sure naming is matching to avoid confusion and make sure the different blake2b variants are properly seperated both in naming and usage)
caching root metadata on the client
Spec curently says that any new cached root metadata should be considered the "trusted root metadata" in future. This is what most clients do: next client startup uses the cached root as the starting point
Best case however would be to always start from the original "out-of-band updated" root since it may be more secure than cached roots (as it may be part of OS image or Debian package and not writable by the user or application like the cached roots are) but to still cache all root versions to avoid unnecessary downloads
Should spec make this clear?
Ideally yes, PR welcome
Does the python-tuf implementation seem reasonable (see PR description)?
Consensus is that many adopters will need all TUF functionality so don't split out "mini-spec"
Guidance for client implementers: "Test what you support"
go-tuf security fixes (one found via conformance test suite)
sigstore plans to drop using go-tuf and bring their own client
go-tuf still maintains dependency on sigstore, unlikely to factor out required code to securesystemslib due to repository governance there
UPDATE: sigstore/sigstore-go contains a wrapper client around go-tuf, so not dropping go-tuf completely but removing it from sigstore/sigstore as far as we can tell
Documentation update. Need reviewers!
September 6, 2024 Meeting
No Meeting
August 2, 2024 Meeting
Attendees
Justin Cappos
Marvin Drees (9elements)
John Kjell
Kairo de Araujo (TestifySec)
Agenda
Discussion go-tuf testing framework update
Discussion about TUF client proxying
Remote proxying ends up meaning you trust the proxy and are reliant on what is likely TLS
Could do local connection proxying, using the OS as a way to validate you're talking to the right party
Github tag version for packages is a good signal if the software is good
DNS, AS, etc. are also decent signals
SOSS EU Kairo will talk about RSTUF
RSTUF Updates
New RSTUF release support offline signing with Sigstore
Kairo is working in a feature (not in current Roadmap) that allows creating delegated Targets that uses offline singing (Sigstore for example) and specific paths, an alternative of using RSTUF with Bins (PEP 458 design)
Kairo shared RSTUF is looking for contributors
PyPI PEP 458: Working in Progres has one PR still in review state, contribution on the review by Datadog
July 12, 2024 Meeting
Meeting date moved so it's not right after July 4th
Consensus is that many adopters will need all TUF functionality so don't split out "mini-spec"
Guidance for client implementers: "Test what you support"
go-tuf security fixes (one found via conformance test suite)
sigstore plans to drop using go-tuf and bring their own client
go-tuf still maintains dependency on sigstore, unlikely to factor out required code to securesystemslib due to repository governance there
UPDATE: sigstore/sigstore-go contains a wrapper client around go-tuf, so not dropping go-tuf completely but removing it from sigstore/sigstore as far as we can tell
Documentation update. Need reviewers!
September 6, 2024 Meeting
No Meeting
August 2, 2024 Meeting
Attendees
Justin Cappos
Marvin Drees (9elements)
John Kjell
Kairo de Araujo (TestifySec)
Agenda
Discussion go-tuf testing framework update
Discussion about TUF client proxying
Remote proxying ends up meaning you trust the proxy and are reliant on what is likely TLS
Could do local connection proxying, using the OS as a way to validate you're talking to the right party
Github tag version for packages is a good signal if the software is good
DNS, AS, etc. are also decent signals
SOSS EU Kairo will talk about RSTUF
RSTUF Updates
New RSTUF release support offline signing with Sigstore
Kairo is working in a feature (not in current Roadmap) that allows creating delegated Targets that uses offline singing (Sigstore for example) and specific paths, an alternative of using RSTUF with Bins (PEP 458 design)
Kairo shared RSTUF is looking for contributors
PyPI PEP 458: Working in Progres has one PR still in review state, contribution on the review by Datadog
July 12, 2024 Meeting
Meeting date moved so it's not right after July 4th
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe