Re: [VOTE] Incorporate SHA256 part of release process
+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 : > > > +1 > > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle: > > joeperciv...@yahoo.com > > > > > > On Thursday, April 14, 2016 7:55 AM, Joe Skora > > 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 "". With the checksum > in > > that format, running "md5sum --check .md5" will checksum > > and verify its checksum matches the expectations. This then > > outputs either ": OK" or ": 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 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 * > > > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > >> > > > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 > > > 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 > > > >> > > > >> > > > >> > > > > > > > > > >
Re: [VOTE] Incorporate SHA256 part of release process
+1 Pierre 2016-04-14 14:24 GMT+02:00 Joe Percivall : > +1 > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle: > joeperciv...@yahoo.com > > > On Thursday, April 14, 2016 7:55 AM, Joe Skora > 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 "". With the checksum in > that format, running "md5sum --check .md5" will checksum > and verify its checksum matches the expectations. This then > outputs either ": OK" or ": 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 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 > > 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 * > > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > >> > > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 > > 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 > > >> > > >> > > >> > > > > >
Re: [VOTE] Incorporate SHA256 part of release process
+1 - - - - - - Joseph Percivalllinkedin.com/in/Percivalle: joeperciv...@yahoo.com On Thursday, April 14, 2016 7:55 AM, Joe Skora 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 "". With the checksum in that format, running "md5sum --check .md5" will checksum and verify its checksum matches the expectations. This then outputs either ": OK" or ": 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 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 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 > 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 * > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 > 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 > >> > >> > >> >
Re: [VOTE] Incorporate SHA256 part of release process
+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 "". With the checksum in that format, running "md5sum --check .md5" will checksum and verify its checksum matches the expectations. This then outputs either ": OK" or ": 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 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 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 > 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 * > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 > 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 > >> > >> > >> >
Re: [VOTE] Incorporate SHA256 part of release process
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 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 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 * >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 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 >> >> >>
Re: [VOTE] Incorporate SHA256 part of release process
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 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 * > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 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 > > >
Re: [VOTE] Incorporate SHA256 part of release process
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 PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Apr 13, 2016, at 6:50 PM, Tony Kurc 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 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 Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Incorporate SHA256 part of release process
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 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 >
Re: [VOTE] Incorporate SHA256 part of release process
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 alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Apr 13, 2016, at 6:33 PM, Matt Burgess wrote: > > +1 > > >> On Apr 13, 2016, at 6:13 PM, Aldrin Piri 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 Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Incorporate SHA256 part of release process
+1 > On Apr 13, 2016, at 6:13 PM, Aldrin Piri 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
Re: [VOTE] Incorporate SHA256 part of release process
+1. I should have done it this time. On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri 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
[VOTE] Incorporate SHA256 part of release process
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
