On Sun, Apr 15, 2018 at 9:30 PM Sean Busbey <bus...@apache.org> wrote:

> On 2018/04/16 01:26:54, Sean Busbey <bus...@apache.org> wrote:
> >
> >
> > On 2018/04/15 21:39:04, Christopher <ctubb...@apache.org> wrote:
> > > On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey <bus...@apache.org>
> wrote:
> > >
> > >
> > > > However, I can't verify that the source artifact or any other
> artifacts
> > > > that we'll eventually place in dist.a.o/release has correct
> checksums that
> > > > meet the current release distribution policy simply because we don't
> have
> > > > the relevant bits posted here in the RC.
> > > >
> > > >
> > > You can't verify the contents of what will eventually be there
> anyway...
> > > anybody could copy things incorrectly. But, they *should* be what was
> in
> > > the staging directory... so you can always do a byte-for-byte
> comparison to
> > > the staging repo (which gets promoted to Maven Central) and verify the
> > > checksum matches that.
> > >
> >
> > Those are very different levels of effort. In one case I can see if the
> thing folks voted on is the thing that's hosted (or at least the thing I
> end up with when I download the thing that's hosted).  the checksums are
> supposed to serve this purpose.
> >
Right now, there is nothing established in policy or official guidelines
that directly serves this provenance purpose. (See [3] for a relevant
discussion on legal-discuss@.) Something that I think gets close might be
in [1] where voters are able to provide additional signatures for a release

Also, let's be careful not to confuse the "Release Policy"[1] (which
governs releasing, voting, and sigs, but does not mention checksums) with
the "Release Distribution Policy"[2] (which governs the distribution
channels provided by Infra, and has the additional requirement for
checksums, but is separate from voting). There is nothing in the "Release
Policy" which suggests that checksums are supposed to serve any purpose...
they aren't even mentioned in the policy which pertains to voting, and the
policy which pertains to the distribution channels neither mentions voting
nor any purpose for the checksums. So no, the checksums are *not* supposed
to serve this purpose.

Regardless, for this release candidate, I've already provided SHA512
checksums in the dist/dev area. Feel free to update your vote accordingly.

In future, rather than maintain parallel staging areas, as I've done for
this release, I think it would be best to tweak the generated email to
simply include the hashes that will be published to the SVN dist/release
area directly in the vote thread (suggested in [3]). Personally, I'd prefer
to include the GPG signatures rather than any checksums, because I think
they are more relevant and useful for vote provenance (and I don't see a
problem with not pre-computing the SHA512 checksum). However, clearly
there's interest in providing pre-computed checksums, so I'd settle for
providing the SHA512 instead... anything to help us avoid two staging areas.

[1]: https://www.apache.org/legal/release-policy.html
[2]: https://www.apache.org/dev/release-distribution.html

Reply via email to