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.) > 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
