Sigstore: Making sure your software is what it claims to be
sigstore.dev
sigstore.dev
It appears the reason to include this system in a toolchain would be to meet compliance requirements, but even the GCP, AWS, and Azure implementations of artifact signing & verification are in beta.
Given how TUF made it particularly hard to implement a system from scratch... How was your experience using Sigstore? Is it designed more around building systems from scratch? I.E. Is it more opinionated?
Thanks.
sigstore is also a transparency log which you can check the signature against, but it's not really necessary, good for public things, you probably don't need it for private / company stuff.
For verification, did you use the policy controller in kubernetes? Or are you manually performing the verification at runtime?
our teams always chose to go with cloud kms services for the signing keys, we thought they offered stronger access controls, and less need to revoke / rotate keys when access changes (team member leaves).
Unless you have some trust relationship with the author, or with someone that audited the code, the whole cryptographically-authenticated chain hangs from nothing.
Tools like Crev did a lot of work in that area but it never really took off, people don't want to think about trust: https://github.com/crev-dev/cargo-crev
Yes; I (along with a bunch of other fantastic folks) implemented it end-to-end for both Homebrew[1] and PyPI[2]. This is at a "lower" level than most corporate uses, however: the goal with integrating Sigstore into these OSS ecosystems is not to build up complex verifiable policies (which OSS maintainers don't want to deal with), but to enable signing with misuse-resistant machine identities.
[1]: https://blog.trailofbits.com/2023/11/06/adding-build-provena...
[2]: https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-dig...
1. It's a repayable bearer token and not a proof of possession. A compromised action (which 99% of people do not pin to specific hashes) could exfiltrate an id token and use it for 15 minutes. 2. There is no proof of provenance of the build machine attached to it all. No attestation about machine state. The only thing you know is "signed by GitHub" which doesn't really tell you anything interesting. Given Microsofts track record of security vulnerabilities in Azure regarding cross-tenant contamination I'd like to see a stronger attestation statement here.
Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key.
Then ideally have an attestation statement that shows you the provenance of the entire machine (what packages , dm-verity hashes, whatever) together with that public key.
Sure it's better than nothing what GitHub has now. And an attack is obvious in hindsight and clearly in the transparency log . But its definitely not a misuse resistent machine identity. We need something better for this IMO.
see the fields in https://docs.github.com/en/actions/security-for-github-actio...
the level of attestation you want (essentially bound to tpms) would probably be very difficult to provide given how all sorts of images run in a typical ci pipeline.
Is it perfect? No, and your point about “true” provenance is a good one: perfect fidelity in provenance would require hardware attestations and a “whole-machine” picture, which is not something that widely adopted CI/CD setups can easily produce at the moment.
> Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key.
That’s how Fulcio works: your public identity is bound as a result of a proof of possession for an ephemeral key and an identity token.
From the bottom of my heart, I wish only the worst things for you in your programming career. Yes, I know that it's still possible to publish packages w/o GitHub, but the technical aspect alone will not convince people in organizations which set policies for how to do this stuff. So, the technical possibility alone doesn't matter. Now a bunch of organizations which advertise themselves as free / OSS have to eat MS proprietary garbage and be grateful... thanks to heroes like you.
It isn’t any harder to publish without before this feature than it is now. In fact it’s easier, because I implemented generic API tokens for PyPI years before this feature, and the feature itself isn’t even tied to GitHub or any particular OIDC IdP. We just picked GitHub as the first external IdP because it is unambiguously the most popular one in the Python ecosystem.
The problem isn't a technical one. The problem is that when a company / government body hears that the "official way to do X is Y", they'll create an internal policy to do Y all the time, regardless of how evil or stupid Y is.
You just destroyed a public good by making a bunch of organizations require the use of GitHub and other MS trash for no technical reason. You are a lot worse than a real estate developer who paved over a community park to build a parking lot for some mega corp. If people saw you doing this in a movie, it would've been so cartoonishly evil, the audience would think the director jumped a shark, yet, real life appears to be worse than the portrayal of evil in art.
It was one of the most-requested features on PyPI, but OK.
The rest of this is just ranting. I think you should develop some more perspective on this, and observe that nobody else is even remotely as bent out of shape as you are over these changes. Which, again, aren't even close to mandatory (and couldn't be even if anybody wanted them to be, which nobody does).
> I think you should develop some more perspective on this
I think you are willfully ignorant, and are upset that I pointed out to you how bad was the thing that you've done. I really don't need a lecturing from some shallow mind that screwed up a lot of people out of their ignorance and unwillingness to educate themselves.
AWS has their firmware image in OSS to be able to reproduce it and then compare the measurements in their Nitro instances: https://github.com/aws/uefi
Azure has confidential compute offerings as well, their attestation, mhsm, ledger services rely on it.
But it is easy to talk about confidential compute and the link between the measurement and the source code. Such link does not exist in regular non-encrypted services and you basically need to trust the service provider about the proofs they give you.
Folks should operate like they already have someone with a leaked instance of their key files. In general, a offline key-self-signing authority issuing client/peer certs is also important, as on rare occasion one can't trust 3rd parties not to re-issue certs for Google/Facebook/Github etc. to jack users.
Eventually one should localize your database design to specific users, and embed user action telemetry into a design. i.e. damage or hostile activity is inherently limited to a specific users content, sanity checking quota systems limit the damage they can cause, and windowed data-lifecycle limits the credentials to read-only or does garbage collection after some time.
In general, the rabbitMQ AMQP over SSL client signed cert credential system has proven rather reliable. Erlang/Elixir is far from perfect, but it can be made fairly robust with firewall rules.
Good luck, YMMV of course... =3
glasklarteknik.se
system-transparency.org
sigsum.org
tillitis.se
This presentation explains the idea and lists similar projects.
Now for the last mile, I'll admit I'm not particularly well-versed on the confidential compute side of things, so bridging the gap from trusted binary to trusted workload is something I can only speculate wildly on. Assuming you have a confidential compute environment that allows for workload attestation, I imagine that you could deploy this trusted binary and record the appropriate provenance information as part of the initial environment attestation report, then provide that to customers on demand (assuming they trust your attestation service).
https://github.com/Azure-Samples/microsoft-azure-attestation...
^^^ note the "Looks up for the MAA x509 extension;" part in the readme.
You can see their attestations in the JWT signing certificates.
Conceptually, you nailed it with the last mile. You want to tie the runtime service's attestation report to the provenance that was generated at build time (and signed by the attested build environment). You can do this by including a copy of it with the service and serving it directly; or the build environment can publish it to a place where clients can later look it up using the Confidential Computing service's attestation measurements.
SLSA is also integrating Confidential Computing as a way to get stronger guarantees about the build environment: https://slsa.dev/spec/draft/attested-build-env-levels#builde... . There was another talk at ACM SCORED about the tradeoffs of hardware-attested vs. reproducible builds: https://dl.acm.org/doi/10.1145/3689944.3696351
[1] - https://gist.github.com/adrianduke/ab40044ccee16804a9d0b2b77... [2] - https://gist.github.com/adrianduke/676ee1ffb88f4489b31aebf5e...
I don’t have a useful proposal for a decentralised version, so I’m just kvetching at this point.
Also, neither X.509 nor JSON is great. We can do better. We should do better.
As for building a decentralized append-only log, that would complicate the design and the threat model quite a bit. In particular it would make proofs of inclusion and consistency much less efficient.
with gpg, you get a root set of public keys that you want to trust. with sigstore, depending on the signing method, you either trust public keys, or identities (some oauth2 identity provider, like email, or your ci system).
> sign. verify. protect. Making sure your software is what it claims to be.
I guess you never used Windows. No amount of signing will prevent it from phoning home. Spyware at its finest.