I'm happy to simply include the SHA in the vote email (which is generated by a script in the release process). There is a broader set of updates that I need to make to the emails and download pages as we've been informed that policy around this has been updated.
On Thu, Feb 12, 2026, at 06:26, Antoine Pitrou wrote: > Hello, > > Le 11/02/2026 à 21:50, Julian Hyde a écrit : >> Thanks for starting this thread, Bryce. >> >> I just voted -1 on the Arrow 23.0.1 RC0 thread, because this needs to be >> resolved. >> >> There does not seem to be a permanent record of the SHA of the RC that >> people vote on. This creates an opportunity for someone to substitute a bad >> .tar.gz for the good .tar.gz at some point after the release vote has >> passed. My concerns were about apache-arrow-adbc-21 but this RC seems to >> have the same problems. >> >> In Calcite, we include the SHA in the vote thread [3] and it is also >> available in the dist/dev tree [4]. That’s belt-and-suspenders; either would >> be sufficient. > > I *can* understand including the SHA in the vote thread, I'm less > convinced about putting it in the dist tree. Assuming the attacker is > able to change the tarball in the dist tree, then presumably they are > also able to change the SHA file to match the new tarball. > > However, the dist tree also contains a GPG signature and that one should > not be possible to forge even if the dist tree is under attacker control > (unless the signing key is compromised, of course). > > So my interpretation of the official rules (laid out in > https://infra.apache.org/release-distribution.html#sigs-and-sums) is > that the SHA only serves for casual download verification (against e.g. > network issues), not to protect against malicious tampering. > > Of course, it would be nice to have confirmation from a voice of > authority, e.g. someone from INFRA or Apache Security. I'm cc'ing Arnout > Engelen (Apache Security Team) in case he's able to shed some light on > the issue. > > Regards > > Antoine.
