As long as your private key is safe, whatever the signed parts are will be tamper proof. Git lets you sign commits; does SVN offer anything similar?
On Mon, Sep 7, 2020 at 10: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.) > > > > > > > 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 > > > > -- Matt Sicker <boa...@gmail.com>
