[VOTE] Incorporate SHA256 part of release process

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Incorporate SHA256 part of release process

Aldrin Piri
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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Joe Witt
+1.  I should have done it this time.

On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Matt Burgess
In reply to this post by Aldrin Piri
+1


> On Apr 13, 2016, at 6:13 PM, Aldrin Piri <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Andy LoPresto-2
Obviously a +1 for me. With regard to the plugin not supporting it, can’t Maven execute arbitrary Java/shell commands during build [1]? The issue on MINSTALL has been open since December 2012. I understand we might need a script wrapper to handle cross-platform functionality, but this might be easier/faster than waiting for MINSTALL team to fix it. 

[1] http://stackoverflow.com/a/3493919/70465
 
Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Apr 13, 2016, at 6:33 PM, Matt Burgess <[hidden email]> wrote:

+1


On Apr 13, 2016, at 6:13 PM, Aldrin Piri <[hidden email]> 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 (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

trkurc
Administrator
In reply to this post by Aldrin Piri
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Andy LoPresto-2
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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]> 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 (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Aldrin Piri
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 <[hidden email]> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

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

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

> On Apr 13, 2016, at 20:13, Aldrin Piri <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> *[hidden email] <[hidden email]>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Joe Skora
+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 <[hidden email]>
wrote:

> Fair enough. OpenSSL is pretty universal, but there are also OS-specific
> commands to perform the same task.
>
> Andy LoPresto
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Apr 13, 2016, at 20:13, Aldrin Piri <[hidden email]> 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 <[hidden email]>
> 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
> >> [hidden email]
> >> *[hidden email] <[hidden email]>*
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]>
> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Joe Percivall
+1
 - - - - - - Joseph Percivalllinkedin.com/in/Percivalle: [hidden email]
 

    On Thursday, April 14, 2016 7:55 AM, Joe Skora <[hidden email]> 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 <[hidden email]>
wrote:

> Fair enough. OpenSSL is pretty universal, but there are also OS-specific
> commands to perform the same task.
>
> Andy LoPresto
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Apr 13, 2016, at 20:13, Aldrin Piri <[hidden email]> 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 <[hidden email]>
> 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
> >> [hidden email]
> >> *[hidden email] <[hidden email]>*
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]>
> 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Pierre Villard
+1

Pierre

2016-04-14 14:24 GMT+02:00 Joe Percivall <[hidden email]>:

> +1
>  - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> [hidden email]
>
>
>     On Thursday, April 14, 2016 7:55 AM, Joe Skora <[hidden email]>
> 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 <
> [hidden email]>
> wrote:
>
> > Fair enough. OpenSSL is pretty universal, but there are also OS-specific
> > commands to perform the same task.
> >
> > Andy LoPresto
> > [hidden email]
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On Apr 13, 2016, at 20:13, Aldrin Piri <[hidden email]> 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 <[hidden email]>
> > 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
> > >> [hidden email]
> > >> *[hidden email] <[hidden email]>*
> > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > >>
> > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]>
> > 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 | Threaded
Open this post in threaded view
|

Re: [VOTE] Incorporate SHA256 part of release process

Michael Moser
+1 from me, too.



On Thu, Apr 14, 2016 at 12:12 PM, Pierre Villard <
[hidden email]> wrote:

> +1
>
> Pierre
>
> 2016-04-14 14:24 GMT+02:00 Joe Percivall <[hidden email]>:
>
> > +1
> >  - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> > [hidden email]
> >
> >
> >     On Thursday, April 14, 2016 7:55 AM, Joe Skora <[hidden email]>
> > 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 <
> > [hidden email]>
> > wrote:
> >
> > > Fair enough. OpenSSL is pretty universal, but there are also
> OS-specific
> > > commands to perform the same task.
> > >
> > > Andy LoPresto
> > > [hidden email]
> > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > >
> > > > On Apr 13, 2016, at 20:13, Aldrin Piri <[hidden email]> 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 <
> [hidden email]>
> > > 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
> > > >> [hidden email]
> > > >> *[hidden email] <[hidden email]>*
> > > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > >>
> > > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc <[hidden email]> 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 <[hidden email]>
> > > 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
> > > >>
> > > >>
> > > >>
> > >
> >
> >
> >
>