Please sign NATS releases

[udf2457]

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]

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]

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]

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.

2. 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:

• Where the source code came from
• Where the binary was built, and how it was built

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]

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]

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]

@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]

@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. 😜