Mailing-List: contact dev-help@nifi.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@nifi.apache.org
MIME-Version: 1.0
In-Reply-To: <20464135.305988.1460636697546.JavaMail.yahoo@mail.yahoo.com>
References: 
 <CAPYoqXSyhj1ac-eMPnAiqZ5N=x=+1m_UrD-O6GLpdg6GNEbTKg@mail.gmail.com>
 <20464135.305988.1460636697546.JavaMail.yahoo@mail.yahoo.com>
From: Pierre Villard <pierre.villard.fr@gmail.com>
Date: Thu, 14 Apr 2016 18:12:22 +0200
Message-ID: 
 <CABgFv27fAwCXp=r5Hy2aDU8AcwqKRbWs6-vJF7r17Bj-YFd+GA@mail.gmail.com>
Subject: Re: [VOTE] Incorporate SHA256 part of release process
To: dev <dev@nifi.apache.org>, Joe Percivall <joepercivall@yahoo.com>
Content-Type: multipart/alternative; boundary=047d7bfd012a2e989f0530742b31

--047d7bfd012a2e989f0530742b31
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

Pierre

2016-04-14 14:24 GMT+02:00 Joe Percivall <joepercivall@yahoo.com.invalid>:

> +1
>  - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> joepercivall@yahoo.com
>
>
>     On Thursday, April 14, 2016 7:55 AM, Joe Skora <jskora@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 i=
n
> 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.apache@gmail.com>
> wrote:
>
> > Fair enough. OpenSSL is pretty universal, but there are also OS-specifi=
c
> > commands to perform the same task.
> >
> > Andy LoPresto
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On Apr 13, 2016, at 20:13, Aldrin Piri <aldrinpiri@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 fe=
el
> > too
> > > brittle across operating systems and this is multiplied in conjunctio=
n
> > with
> > > a maintained follow on script(s).  Overall would prefer just incurrin=
g
> > 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 <alopresto@apache.org=
>
> > wrote:
> > >>
> > >> Tony,
> > >>
> > >> That=E2=80=99s definitely a valid concern that I=E2=80=99m sure bene=
fits all release
> > >> managers to review. The conversation below is regarding the checksum=
s
> > for
> > >> data integrity only; not the underlying hash used in the GPG signatu=
re
> > >> process.
> > >>
> > >> Andy LoPresto
> > >> alopresto@apache.org
> > >> *alopresto.apache@gmail.com <alopresto.apache@gmail.com>*
> > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > >>
> > >> On Apr 13, 2016, at 6:50 PM, Tony Kurc <trkurc@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 preferr=
ed
> > 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 <aldrinpiri@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 fa=
ll
> > on
> > >> the RM to do so but could easily be added to the documentation we ha=
ve
> > >> 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
> > >>
> > >>
> > >>
> >
>
>
>

--047d7bfd012a2e989f0530742b31--