+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
> >>
> >>
> >>
>
