As far as the wrapper script, I'm in favor of the manual process for the SHA256. The arbitrary shell commands/processes in the Maven build feel too brittle across operating systems and this is multiplied in conjunction with a maintained follow on script(s). Overall would prefer just incurring the "expense" on the RM to do so manually once these artifacts have been generated through the process currently in place.
On Wed, Apr 13, 2016 at 9:58 PM, Andy LoPresto <alopre...@apache.org> wrote: > 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 > alopre...@apache.org > *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Apr 13, 2016, at 6:50 PM, Tony Kurc <trk...@gmail.com> 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 <aldrinp...@gmail.com> 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 > > >
