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 candidate. 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. Thanks. 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 [3]: https://lists.apache.org/thread.html/bb7281ed8da0ceaa5f0f18e3edc6c3f728c74d7ed8c4df12729b6f40@%3Clegal-discuss.apache.org%3E
