Fair enough. OpenSSL is pretty universal, but there are also OS-specific 
commands to perform the same task. 

Andy LoPresto
[email protected]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Apr 13, 2016, at 20:13, Aldrin Piri <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> *[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
>> 
>> 
>> 

Reply via email to