trishankdatadog

python-tuf [1] back then assumed that everything was manipulated locally, yes, but a lot has changed since then: you can now read/write metadata entirely in memory, and integrate with different key management backend systems such as GCP.

More importantly, I should point out that while Sigstore's Fulcio will help with key management (think of it as a managed GPG, if you will), it will not help with securely mapping software projects to their respective OIDC identities. Without this, how will verifiers know in a secure yet scalable way which Fulcio keys _should_ be used? Otherwise, we would then be back to the GPG PKI problem with its web of trust.

This is where PEP 480 [2] can help: you can use TUF (especially after TAP 18 [3]) to do this secure mapping. Marina Moore has also written a proposal called Transparent TUF [4] for having Sigstore manage such a TUF repository for registries like PyPI. This is not to mention the other benefits that TUF can give you (e.g., protection from freeze, rollback, and mix-and-match attacks). We should definitely continue discussing this sometime.

[1] https://github.com/theupdateframework/python-tuf

[2] https://peps.python.org/pep-0480/

[3] https://github.com/theupdateframework/taps/blob/master/tap18...

[4] https://docs.google.com/document/d/1WPOXLMV1ASQryTRZJbdg3wWR...

> >The complexity designed into this system might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.

I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as, say, devising an in-toto root layout. Most open source projects should really just worry about subscribing to something like PEP 480 and signing with one-time Fulcio keys. But I think we are largely on the same page here: yes, please just minisign/signify if you want simplicity, but if you want resilience from nation-state attacks, you need something like TUF (coupled with in-toto and sigstore). We are happy to advise.

Thanks for the TUF shoutout!

Yes, we (Datadog Agent integrations) were one of the early adopters mentioned, please see our blog post [1].

Also, really, the TLDR should be just use TUF + in-toto already.

[1] https://www.datadoghq.com/blog/engineering/secure-publicatio...

Reupping my comment [1] from the last discussion:

> Agreed: adding port-knocking and fail2ban in addition to passwordless should not be and are not silly ideas.

[1] https://news.ycombinator.com/item?id=24446577

signify is nice when key distribution, revocation, and rotation is handled for you... but how do you do that securely for many different publishers on a single repo?

> software update cryptography is both a solved problem (just use signify)

Well, just use TUF [1] and in-toto [2] ;)

[1] https://theupdateframework.io/

[2] https://in-toto.io/

Agreed: adding port-knocking and fail2ban in addition to passwordless should not be and are not silly ideas.

Yes, please see PEP 458: https://www.python.org/dev/peps/pep-0458/

LMAO, funniest thread all day

Yes, I talked about it:

https://news.ycombinator.com/item?id=24371628

Philip is right: they are complementary:

https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...

Apply pattern/toolset recursively. Software supply chain problems largely eventually solved this way.

Don't miss how we used TUF [1] and in-toto [2] to build compromise-resilient CI/CD (the first in the industry AFAICT) for the Datadog Agent integrations [3][4] that detects attacks anywhere between our developers and end-users

[1] https://theupdateframework.io/

[2] https://in-toto.io/

[3] https://www.youtube.com/watch?v=9hCiHr1f0zM

[4] https://dtdg.co/integrations-tuf-in-toto

Little-known fact: like Google Fuchsia, Bottlerocket uses The Update Framework (TUF)[1][2] to securely update itself!

[1] https://theupdateframework.io/

[2] https://github.com/awslabs/tough

It's not well-documented, but non-FIPS can support 4096. FIPS goes up to 3072 for, well, FIPS reasons.

Anyway, how to generate GPG keys on YubiKey in ~15m: https://github.com/DataDog/yubikey

CI/CD is critical to any DevOps operation today, but when attackers compromise it, they get to distribute malicious software to millions of unsuspecting users. We present how Datadog used TUF and in-toto to develop, to the best of our knowledge, the industry’s first end-to-end verified pipeline that automatically builds integrations for the Datadog agent. That is, even if this pipeline is compromised, users should not be able to install malware. We will show a demonstration of our pipeline in production being used to protect users of the Datadog agent, and describe how you can use TUF + in-toto to secure your own pipeline.

Nassim Taleb has been saying this forever, he first talked about it in at least Antifragile IIRC.

"AGL includes the meta-updater Yocto layer that enables OTA software updates via Uptane, an automotive-specific extension to The Update Framework. Uptane and TUF are open standards that define a secure protocol for delivering and verifying updates even when the servers and network–internet and car-internal–aren’t fully trusted."

https://docs.automotivelinux.org/docs/en/master/architecture...

Sure, but most SSH servers probably don't support FIDO2 yet (GitHub didn't the last time I checked).

Also, please sign your git commits.

BTW, here is a handy way to quickly generate GPG keys (and set up git commit signing and SSH key derivation) on Yubikey: https://github.com/DataDog/yubikey

my bad, but still, no reply as yet...

Hi Travis,

If you are reading this, I'm one of the members of the TUF [1] and in-toto [2] team, where we try to solve exactly this kind of problems. While I agree with you that reproducible builds sound a lot simpler than they actually are to achieve (and leaving aside all the practical complexities you mentioned in the blog post), I think they provide value for a certain use case seemingly not mentioned in the blog post.

It is the case where the vendor is a traditional Linux distro, and we have independent reproducible builders to ensure that a compromise of their CI/CD infrastructure is not enough to cause malware to be installed. It is true that the builders can still go off and reproducibly build malicious code, but this can be mitigated by requiring a high enough threshold of (presumably independent) developers to sign off the code. The problem of malicious source code is infeasible if not impossible to solve cryptographically, but we can make sure that CI/CD increasingly sitting on the cloud are not blindly trusted.

Could not post on your blog. Let me know what you think. Thanks!

[1] https://theupdateframework.io/ [2] https://in-toto.io/

Strange comment. I'm not sorry you're not sorry either.

The problem with Transparent Logs / Certificate Transparency is that they don't have the best story with regarding to recovering from compromise. We wrote an article comparing The Update Framework (TUF) to CT/TL:

https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...

n=2 anecdata: no problems updating two MacBook Pros from 2017 and 2018, which were also already on Catalina.

15 minutes could save you 15% on your cybersecurity insurance or more: https://github.com/DataDog/yubikey