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.
