Thanks for the detailed feedback! > 1. The list of applicable signing keys included in the tarballs and elsewhere > only lists the fingerprints
We'll fix that. > 2. The list seems kind of long, are all these people really authorized to > decide which release tarballs are real? Yes any member of the dev team can put out a release. Our goal is that, eventually, everyone be experienced in doing so. There used to be a shared release key, but individual keys provides better identification. (Putting out a release does require another team member to review it, by the way.) > 3. The list contains a lot of old MD5 fingerprints and seemingly To be fixed as part of #1 > 4. Some releases are signed with keys not on the list in the previous > tarball, breaking the chain of trust. We had a key-signing ceremony at the recent F2F, so this should be better addressed now. > 5. As an SSL/X.509/SMIME library, you have a strange preference for PGP/GPG > keys. :) PGP has market dominance for software distributions. > 6. The SSL certificate for www.openssl.org is of the lowest trust grade > available (domain validated only). That's an interesting idea, and something we'll pursue after a couple of other changes happen. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz
