Tony, That’s definitely a valid concern that I’m sure benefits all release managers to review. The conversation below is regarding the checksums for data integrity only; not the underlying hash used in the GPG signature process.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Apr 13, 2016, at 6:50 PM, Tony Kurc <[email protected]> wrote: > > I was under the impression not using SHA-1 WAS part of our release, when we > were gpg signing (based off of [1]), which I assumed was the preferred form > of assuring an artifact was not "bad". However, it looks like it isn't in > our checklist to confirm that SHA-1 wasn't used to make the digital > signature, and it looks like 0.6.1 is using SHA1. > > > 1. http://www.apache.org/dev/openpgp.html#key-gen-avoid-sha1 > > > > > On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri <[email protected]> wrote: > >> This was mentioned in the vote thread for the RC2 release and wanted to >> separate it out to keep the release messaging streamlined. As mentioned by >> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I >> like having this as part of the official release process as I typically >> generate this myself when updating the associated Homebrew formula with no >> real connection to the artifacts created other than me saying so. >> >> The drawback is that the Maven plugins that drives the release >> unfortunately does not support SHA-256.[1] As a result this would fall on >> the RM to do so but could easily be added to the documentation we have >> until the linked ticket is resolved. >> >> This vote will be a lazy consensus and remain open for 72 hours. >> >> >> [1] https://issues.apache.org/jira/browse/MINSTALL-82 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
