search

nats-io / nats-server

High-Performance server for NATS.io, the cloud and edge native messaging system.
https://nats.io
Apache License 2.0
16.04k stars 1.41k forks source link

Please sign NATS releases #5325

Open udf2457 opened 7 months ago

udf2457 commented 7 months ago

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

udf2457 commented 7 months ago

Useful references: https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-for-goreleaser https://goreleaser.com/blog/slsa-generation-for-your-artifacts/#slsa-github-generator

tcali101 commented 7 months ago

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.

udf2457 commented 7 months ago

Two ways I could approach answering your question....

  1. Competition

Rabbit sign their releases, Kafka sign their releases .....

I assume NATS likes to consider itself as an alternative to those ? In which case, you might have to "suck it up buttercup" and sign those releases. You might consider it "compliance bingo" but if you want a shot at getting into compliance-heavy environments then why resist such an easy way to tick an important box ? Especially when it is both free and easy.

  1. Addressing your point specifically

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.

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 xz style commit happens, with provenance, I have a way of verifying I'm still using a safe binary (either before the commit, or after you have rolled-back a malicious commit). With a shasum, I have none of that possibility (well, at least not in such an efficient and simple way).

philpennock commented 7 months ago

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!

udf2457 commented 7 months ago

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 mtail and all it took was 29 lines in their Github workflow. They used the two links posted above as a basis.

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.

tcali101 commented 7 months ago

@udf2457 So you don't just want "binary signing" (which was your initial request in the first post, consider updating it to be more specific). You would rather have the SASL, which is much more than just binary signing: https://slsa.dev/.

I just checked the Kafka 3.7.0 JAR file for signing; Kafka jar files are not signed. Just for your information:

kafka_2.13-3.7.0\libs>jarsigner -verify kafka_2.13-3.7.0.jar
jar is unsigned.

kafka_2.13-3.7.0\libs>jarsigner -verify kafka-clients-3.7.0.jar
jar is unsigned.
udf2457 commented 7 months ago

@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. :stuck_out_tongue_winking_eye: