On Mon, 7 Sep 2020 at 16:12, Mark Thomas <ma...@apache.org> wrote: > > On 07/09/2020 15:26, sebb wrote: > > Suppose we take the following example: > > > > https://lists.apache.org/thread.html/c99519e1c8e0a4af5be02f40e8e44b408cbc3d4568a334f3a400b94f%40%3Cdev.commons.apache.org%3E > > > > This is Commons Daemon 1.2.0 based on RC2. > > > > Take for example: > > > > https://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.2.0-native-src.tar.gz > > with sha256: > > 13c8d9b27d38ae1ced1fb37743239035cd1add74a8ef20bfce38386fc0b4a243 > > *commons-daemon-1.2.0-native-src.tar.gz > > > > How does one show that it is the same source that was voted on? > > Via the svn revision. > > At the time of the release vote it is easy to check e.g. by checking for > commit messages to /dev/commons/daemon both for the original upload and > to see if any changes were made. That takes a few seconds. > > For an historical release you'd need to do something like: > svn log https://dist.apache.org/repos/dist/dev/commons/daemon > svn log https://dist.apache.org/repos/dist/release/commons/daemon > > With those you can trace the files back to the release vote. > > Depending on the level of "proof" you are looking for, you may want to > check out the specific svn revision. > > Taking things to extremes, you are relying on the archives not having > been tampered with which I think is a reasonable assumption but if you > are looking for absolute proof the process does fall down there. > > Yes that takes work, but not that much more than generating the hashes > for the vote vote. Yes, hashes in the vote email would short-circuit a > lot of that work. But it is work I am not aware of the ASF every being > required to do. Adding the hashes takes time for every single release. > Even if we had to manually verify every 100th release it would be less > work not to generate the hashes in the vote email. (Automation would > probably change that equation.)
Such automation already exists, and is used to generate the VOTE emails used by many Commons RMs $ mvn commons-release:vote-txt > > > Also the Maven jar: > > > > commons-daemon-1.2.0.jar > > sha1: > > a3a42da759a94a0522fe4b867ac2f5d0d58cc0a9 > > Nexus log messages to the mailing list. E.g. > > https://lists.apache.org/thread.html/e3d65d1bb28b631d58d273a15953f365ab6e85a739e7ea26383ac74c%40%3Ccommits.commons.apache.org%3E > > and > > https://lists.apache.org/thread.html/a3db1d2c76fc02a9076e1d7d611b60c430828c9625f9dde2d9638e1d%40%3Ccommits.commons.apache.org%3E > > The staging ID (also in the vote thread) is in the first message and you > can cross-check the hashes across both messages and with the artefacts > in Maven Central. > > Again I agree that takes work. Again, I would contend it is more > efficient to do this additional work in the (very) rare cases we need to > and rather than spend time on the premature optimisation of including > hashes in release votes. And again, automation would like change that > equation. > > Mark > > > > > > Sebb. > > > > On Mon, 7 Sep 2020 at 14:16, Gilles Sadowski <gillese...@gmail.com> wrote: > >> > >> Hello. > >> > >>>> [...] > >>>> see an explanation for why it is necessary > >>>> (or even helpful) to include artefact hashes in the vote mail. > >>>> > >>> I agree and understand all your points here. > >> > >> Well, I don't. > >> An explanation would be useful indeed. > >> > >>>> Validating the svn revision for the dist repo [ ... vs ...] > >>>> comparing the hashes of each file to a hash provided in > >>>> the vote email. [...] > >>> > >>> I was merely trying to offer the opposing perspective of the other folks. > >> > >> Aren't we talking about a *requirement*? > >> Referring to the "executive summary" above (as I understand it), > >> from Mark's edited text, which information is necessary and sufficient > >> for a vote? > >> > >> Also, isn't this discussion a rehash of my (recurrent) question > >> about whether the hash checks should be automated? > >> [I mean, isn't it sufficient that the RM would indicate in the vote > >> email that the hash values stored in the "dist" area are the same > >> as those generated by the build?] > >> > >> Regards, > >> Gilles > >> > >>>>> [...] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
