New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please sign NATS releases #5325
Comments
May I ask what your threat model is? Usually, code signing is just compliance bingo. Someone likes to check a checkbox on their bingo card. If an attacker can take over the Nats github account, there is a high chance that he can also create maliciously signed binaries for distribution. If you need high security, request reproducible builds, see https://reproducible-builds.org/, and build and sign it yourself. |
Two ways I could approach answering your question....
Rabbit sign their releases, Kafka sign their releases ..... I assume NATS likes to consider itself as an alternative to those ?
Well sure, but you are missing the point entirely. The point of something like SLSA is that you are able to demonstrate PROVENANCE. Provenance means that you provide me with a method to verify:
To spell it out: it means I can take a NATS binary. I can be absolutely 100% certain that binary was built by the Github CI/CD runner. I can be absolutely 100% certain that the Github CI/CD runner built that binary from a specific commit. A shasum tells me none of that. Not even close. Its called traceability and auditability. A shasum provides neither. If a bad |
With my NATS Security hat on: I am a fan of signing, as long as the signature tells you something meaningful. I've been following along with cosign for a while and using it in some small tools we have, but also following along with API breakages and fun with making sure that signatures are useful and meaningfully verifiable. But, I think that the basic keyless signing flows are about stable now, so it's back on our plate to look at some more. (Still hoping for saner verification flows which don't over/under specify and make it hard to ask for meaningful things) For certain products from Synadia, we do cosign key-based signed releases and reproducible builds. That's somewhat proven out that this works and we can do the same for the OSS projects too, switching to keyless. We are highly likely to use cosign with keyless signing and GitHub token for OIDC exchange for identity, and probably building the nats-server for reproducible builds. I don't have a specific timeline for this right now, but this issue has nudged people and has put it on the scheduling roadmap, so thank you! |
I do agree that pre-keyless it was a PITA to sign stuff with PGP or whatever. But SLSA has changed that, and as you say, the workflows are now very stable, perhaps especially for Go code. For example, I nudged the guys over at To be clear: No doubt there's scope for some to nitpick on the workflow code I just linked to, but the point I'm making is more about the simplicity of concept rather than suggesting you copy paste, clearly that's not my intention. |
@udf2457 I just checked the Kafka 3.7.0 JAR file for signing; Kafka jar files are not signed. Just for your information:
|
@tcali101 Clearly the Kafka are signed the old-school way. I think the whole world agrees the way forward is SLSA style. I think I made my point clear in (2). My point about the competition was just "as an aside". Indeed, NATS would be better than the competition if you signed with SLSA and they only signed old-school. 😜 |
Proposed change
Its 2024, not signing releases and just relying on hashes is not cool. :sad
It is also easier than ever to do. You can even do it fully-automated via Github Actions, Github OIDC and Sigstore "keyless" signing.
Use case
Its 2024, not signing releases and just relying on hashes is not cool. 😞
Contribution
No response
The text was updated successfully, but these errors were encountered: