On Wed, Feb 11, 2026 at 10:27 PM Antoine Pitrou <[email protected]> wrote:
> 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. Thanks for looping me in. I agree it is important to include something in the vote thread that makes it clear what exactly has been voted on. This could be either the checksum or a VCS ID (e.g. git hash), assuming as part of the checking/voting you verify their contents match. This is separate from the signature, as any individual with access to a key in the KEYS file can create a valid signature, and only coupled with the appropriate votes it becomes a 'release'. I personally like to repeat the hash in my vote, though it is likely sufficient for it to be present anywhere in the thread. While I have a strong preference to include it, I cannot find any explicit policy in https://infra.apache.org/release-distribution.html#sigs-and-sums saying the hash is formally required to be part of the vote. Hopefully ATR (https://release-test.apache.org/docs/introduction-to-atr) will make sure hashes are part of the vote thread, and eventually provide an additional layer making it harder to tamper with the artifacts after the vote has been started (even if the actual votes remain the ultimate 'source of truth'). Kind regards, -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant
