+1 from me, too.
On Thu, Apr 14, 2016 at 12:12 PM, Pierre Villard < pierre.villard...@gmail.com> wrote: > +1 > > Pierre > > 2016-04-14 14:24 GMT+02:00 Joe Percivall <joeperciv...@yahoo.com.invalid>: > > > +1 > > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle: > > joeperciv...@yahoo.com > > > > > > On Thursday, April 14, 2016 7:55 AM, Joe Skora <jsk...@gmail.com> > > wrote: > > > > > > +1 for SHA256 > > > > Whatever process produces the checksums it would be nice if the checksum > > files could be made compatible with the "--check" option on the md5sum, > > sha1sum, and sha256sum commands to simplify validation. > > > > That format is "<checksum><space><space><filename>". With the checksum > in > > that format, running "md5sum --check <filename>.md5" will checksum > > <filename> and verify its checksum matches the expectations. This then > > outputs either "<filename>: OK" or "<filename>: FAILED" eliminating the > > need to eyeball checksums and also making it easier to script the > > validation if needed. > > > > > > > > On Wed, Apr 13, 2016 at 11:20 PM, Andy LoPresto < > > alopresto.apa...@gmail.com> > > wrote: > > > > > Fair enough. OpenSSL is pretty universal, but there are also > OS-specific > > > commands to perform the same task. > > > > > > Andy LoPresto > > > alopresto.apa...@gmail.com > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > > > On Apr 13, 2016, at 20:13, Aldrin Piri <aldrinp...@gmail.com> wrote: > > > > > > > > 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 > > > >> > > > >> > > > >> > > > > > > > > > >
