Yes, I screwed up. Everyone who voted screwed up. I should have voted ‘-1’ because the hash of the artifacts I got from svn did not match the hash in the email. Let’s all do better next time.
Still, no harm done. We know now that we were voting on the correct artifacts. We have a valid release. Julian > On Sep 12, 2019, at 5:54 AM, Michael Mior <mm...@apache.org> wrote: > > +1 to everything Vladmir said. Thanks for the release Stamatis! I do > agree that the checksum issue shouldn't be ignored although an update > from the RM to the vote thread should be sufficient. Really, we rely > on the email of the RM not being compromised anyway if we assume we > can have a MITM between us and the hosted files. > -- > Michael Mior > mm...@apache.org > > Le jeu. 12 sept. 2019 à 06:59, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> a écrit : >> >> Stamatis, thanks for your work on this. >> >> Stamatis>The checksum hash that was communicated in the vote email was wrong >> Stamatis>given >> Stamatis>that the correct one was send along with the artifacts and people >> used this >> Stamatis>for the checks I assume there is no problem. >> >> I'm inclined that we should vote with -1 (or wait for RM to send the >> updated checksum) when checksum in the mail does not match to the checksum >> of the archive. >> >> Well, it is OK, if release manager sends updates, however it should not be >> the case that actual checksum >> differs from the one that was suggested in the vote mail. >> >> Different checksums might mean there's MITM attempt, and it sounds wrong >> that we "kind of ignore it". >> Even though I agree the impact in this case was quite low (e.g. I've >> personally verified PGP signature and ensured it was SHA512 based), we >> would probably want to refrain from repeating that practice. >> >> I would like to follow https://reproducible-builds.org/ to simplify release >> validation. >> >> Vladimir
