Cryptopp: Crypto++ and Release Signing

[noloader]

A few of our responsibilities include coordinating with the distributions on security issues, coordinating with the distributions releases, and support distros in packaging the library to ensure the best deliverable. When we release, we coordinate with our package maintainers to give them a "heads up".

We received some feedback from the openSUSE folks. It reiterates some sentiments of Debian and Fedora:

3. you could create and publish a PGP signature for the .zip file

so that we know that it is really the version you made
and not the one some hacker uploaded to your server (and updated
the hashes next to it)
https://www.cryptopp.com/cryptopp564.zip.asc
would be a nice URL for that.

3 is especially nice for openSUSE because we have mechanisms to

automatically fetch and verify such sigs, reducing the work of
verifying the authenticity to zero.

This report tracks the initiative of signing releases.

I believe this would benefit both distros and users, so it has larger scope than maintaining relationships with distros. There's also an intersection with repackagers who have been known to insert additional cruft into archives and installers.

Try not to wander too far into policy and procedure at this point in time. Policy and procedure would include things like who has access to the private key, how the private key is distributed, and how the private key is stored. Let's focus on whether its a good idea to sign releases; and if so, then should this project do it.

[bmwiedemann]

yes, it is a good idea and you should do it.

On the matter of private keys:
I think, if you want to use public-key crypto (such as PGP keys) correctly, the private key should be created in one place and never leave it.
If other people need a private key, they create one in the same way and their public key is added to the list of "trusted public keys of developers".
This way, if one of the keys gets lost, you get to learn which one and only need to replace that one.

If you wanted to avoid multiple distributions having to update that list of trusted public keys, there could be a release-bot in a safe location handling the 'official' release signing key that has that list of trusted public keys. E.g. any trusted developer could send it a signed email with the to-be-signed release.zip and it would return the official sig.

[DevJPM]

Let's focus on whether its a good idea to sign releases

Yes.
Generally, it's always a good idea to allow people to verify the integrity of projects, especially if their security depends on this property. While we offer this with our HTTPS + hash setup right now, even our servers aren't resistant to compromise, especially since we all have so few spare cycles and properly sysadmin'ing and hardening a box is non-trivial. Furthermore HTTPS + hash has its own issues, as it's harder to do an automatic verification (as the package maintenainers want to do) of releases and packages, if dedicated hash files aren't provided (which we don't AFAIK).

and if so, then should this project do it.

Again, yes.
If the operational cost isn't too high, e.g. it would eat waaay to much time, I'm all for signing our releases and giving people a consistent and verifieable way to check the integrity of our project.
Bonus: Remember why we moved away from SourceForge? They inserted ads into open-source projects (e.g. they modified them in an "uncontrolled" way). If we sign releases, this sort of uncertainity would be gone.

As requested, I won't yet comment on procedures and policies :)

[bmwiedemann]

Automating the HTTPS + hash verification would be a lot easier, if there was a standalone hash file in a predictable location e.g.
https://www.cryptopp.com/cryptopp564.zip.sha1
because we certainly would not want to write a HTML-parser that is specific to one of the thousands of projects in openSUSE.
But the .asc is a lot better than that anyway, so dont waste time on hashes.

[noloader]

@bmwiedemann, @DevJPM, @denisbider, @mouse07410,

I pinged Wei on a sidebar and asked "Do you have any thoughts on [code signing] and referenced this issue". He responded with a "No particular preference". That's a good sign, so I think we will be able to proceed.

I don't foresee this initiative stalling or failing. Let's start thinking about how to do it. We are now moving towards the "policy and procedure" portion. I'll get a wiki page set up release signing policy and procedures so we have a "living document" to work from. We can bounce ideas here, and then merge the into the wiki.

[DevJPM]

Ok so here are the questions we need to answer:

• What will we sign? (only full releases or also the master branch in regular intervals?)
• Where will the private key be? (encrypted software storage? smartcard? HSM? cloud-server?)
• Who will be allowed to sign? (Wei? Jeff? Uri? Denis? Me? ...)
• Can we only use a single key for signing or can we create a set of valid keys for signing?
• If it involves HW / cloud storage, who will come up for the fees / costs?

[DevJPM]

OK, so let's see what I can suggest as answers to my above questions:

What will we sign?

Let's go the obvious route for now and only sign releases. The master branch should be "secured" using commit and merge-signing as per Issue #290 .

Where will the private key be?

Personally I'd feel safer with a smartcard (and multiple backup copies) and a key ceremony to attest proper key generation and distribution. However I'm certain that nobody will be with me (especially considering cost and required organizational and logistical effort), so my answer is:
Encrypted software keys. There should be at least two copies of the private key floating around, at the persons who are supposed to use the keys. Other persons may be given a backup copy without a password. These persons (one-after-one) would probably be given access when the two current main operators cease availability.
I'll leave the details of how one could properly create and share the private key out for now (upon further request).

Who will be allowed to sign?

The person who _does_ the releases, i.e. uploads them to the website (aka Jeff), should be allowed to sign, along with Wei. If either of those two people doesn't want to operate the release-signing anymore a successor should be found quickly, so not everything hangs on a single person to make a critical release if neccessary.

Can we only use a single key for signing or can we create a set of valid keys for signing?

I still don't know whether this is a thing, but for now will assume we can only use a single public / private key pair. If the situation is different please tell, this would change the way the key distribution works.

If it involves HW / cloud storage, who will come up for the fees / costs?

This answer assumes software storage, so the only cost will be CDs / mail probably, which I hope the participants of the initial key installement can take.

[bmwiedemann]

I can agree with the answers 1 and 3, but still think that individual keys are the better thing to do. It avoids having to move private keys around the world in a secure way, and emphasizes the responsibility of individuals.

Instead of a single key-creation ceremony it is a lot better to have other people sign your public key anytime later, to build a web-of-trust.
Looks more like
https://pgp.mit.edu/pks/lookup?search=bwiedemann@suse&op=vindex
instead of
https://pgp.mit.edu/pks/lookup?search=Jeffrey+Walton&op=vindex

[AraHaan]

hmm I think having the official website getting an api that makes trusted devs to crypto++ to be able to sign it with a special endpoint in the official site _(if it has an api, if not then make one just for signing if possible)_ that way all they have to do is send in a json like payload (with the zip file of the stuff to sign base64 encoded with a email / password that is given to them when they are trusted or are set to do the signing) so that way the website takes that base64 data and decodes it, reads the stuff and signs it and then base 64 encodes the signed data and responds with that data, then the signee / trusted dev would have to base64 decode that stuff and then have it uploaded to the official site. I know this might sound difficult but it could be possible.

[noloader]

We are going to start Release Signing for the Crypto++ 8.0 release. Authorized release agents will be listed at Release Signing along with their keys.

I'll probably go back and release sign some of the former releases.