Signed releases

[miyashitatouka]

I see the latest version's git tag was PGP signed by someone other than the github-actions bot. That's great. Downstream packagers really appreciate authenticity from upstream projects. I have two questions then:

• Can we count on future releases being signed by Felix Handte's key (B774B0A2C0A08A8A7C1D3EF499B5DE0B30966569)?

• If so, could we please also get signed tarball releases with this key, including one for 1.4.9?

[felixhandte]

Hi! I'm surprised you noticed. This is something I did as an experiment. I wasn't sure to what extent people care about this or whether it would replace or just supplement the GitHub signature (although how valuable is that signature really?).

We generally rotate responsibility for the release process amongst the team members. So, no, we won't use my key for every future release. But if there's interest, we could probably set up a signing key for the project.

[anthraxx]

There is a huge interest in this from Arch Linux and I'm sure others would benefit and be grateful about this bit of the supply chain security as well. GitHub signature are in my humble opinion the worst feature ever invented, it gives virtually zero benefit and weighs some people in false security -- signature on a project level should exclusively authenticate the developers and project owners which is the only legitimacy that really matters, contrary to the used platform.

A dedicated project signing key makes sense, however if it ever gets rotated please make sure to provide a chain of trust with either cleartext sigs of the old key legitimizing the new key or do cross key sigs 🐱 Sorry if this got a wall of text and it all seems super obvious to you, I'm nowadays just mentioning all this because I've seen way too many projects doing this wrong and feel like it can't hurt to throw in some of my views and experience to avoid running into problems again 🐈

[miyashitatouka]

A single project key would be much appreciated!

[felixhandte]

So, input would be appreciated on this topic. It seems like we have a number of options about how we could set this up.

I think the biggest question is: Is it more valuable to have the release tag itself signed? Or the tarballs? (Or both?)

Also: Is it valuable to produce and sign binaries for OS X and Windows? (This one seems less likely since it would be a lot more setup work on our end.)

[anthraxx]

@felixhandte the more the merrier 🐱
Speaking from a Linux perspective:
I would say the MVP would be to sign the tarballs -- as the tarballs are the officially distributed containers that are meant for downstream projects to consume. It would therefor totally make sense to provide them in a way that the authenticity could be verified.

Signing the corresponding tag would be a nice bonus. There are some distros that nowadays tend to pull from git and populate the source tree with distro specific build instructions, they would have easier ways to check the authenticity if they would like to.

[felixhandte]

Ok. We've created the key 28B52FFD available at http://zstd.net/signing-key.asc.

Future releases will use this key to sign tarballs at least. We'll think about also signing the tags, but we don't have a good way to do that systematically.