WARNING: this post mixes public and private lists. In Commons reviewers are supposed to check that the source tarball contents all match files from the tag in the vote. The reason is mainly for provenance, and licensing, but it is not unknown for spurious files to be accidentally added to the source tarball. Things can go wrong even without malicious intent.
So I agree that this is a vital part of the process, and should be made explicit. On Tue, 2 Apr 2024 at 07:52, Jarek Potiuk <ja...@potiuk.com> wrote: > > Following some of the learnings from the CVE-2024-3094 (xz backdoor) and a > few resulting discussions. I would like to start a discussion on that very > specific topic: > > TL;DR; I think that we currently do not explicitly state the requirement of > verifying if the release manager has not tampered with the sources when > preparing the source package - and I believe we should be more explicit about > it and require from PMC members to do such verification. > > As explained in [1] - there were two important triggers for the CVE to happen: > > a) the attacker was able to gain trust, become a maintainer and release > manager > b) they submitted test binaries to the repository of xv that contained > malicious code > c) acting as release manager - they modified the official source tar-ball > packages of xz to contain a modified Makefile that turn anyone using official > source-tar-ball packages to produce a malicious version of the xz library > (that malicious Makefile had never been part of the source repository, it's > not been reviewed nor approved by anyone). > > When I look at requirements explained in our release policy, I think this > kind of scenario (especially point c) is not something our release policies > protect us against, because we have no requirement to check provenance of the > source code in the released package. > > Or at least I cannot find it in neither release policy [2] nor distribution > policy [3]. > > From [2]: > > > Before casting +1 binding votes, individuals are REQUIRED to download all > > signed source code packages onto their own hardware, verify that they meet > > all requirements of ASF policy on releases as described below, validate all > > cryptographic signatures, compile as provided, and test the result on their > > own platform. > > Even if we assume such a check is part of "meet all requirements of ASF > policy on releases" - there is no "check if the sources in the package have > not been modified vs. source repository" anywhere in the policies as far as I > can see. > > From earlier discussions - many of us think that verifying whether the > sources in the "source" package contain the same sources as ones stored in > our source repositories is the most important part of such verification, but > - somewhat to my surprise - it has not been explicitly stated in our > policies. And I think it should be an important gate to have PMC members to > be REQUIRED to verify that. That could be done in whatever way is appropriate > for the project - it could be just comparing sources with git, or having > reproducible packages that PMC members can build and compare for binary > identity if the project supports it. > > But similarly to comparing cryptographic signatures, possibly we should > explicitly state that this should be a mandatory check. And maybe we have the > chance to use the CVE-2024-3094 as an opportunity to remind/advocate it and > explain what could happen if this step is missing when our source packages > are released? > > I think the way it's stated, a malicious release manager could do a similar > package modification as xz release manager did and we could have missed it. > Our policies on release do not have explicit gates protecting against this - > so PMC members explicitly give +1 - following the release policy pretty > rigorously, could have not realise the malicious release manager did such > > Just to give an example from the past Airflow releases - when I came to the > project, I've learned how it works, and the release process was very > rigorously followed, including licences, signatures, etc. and we even pulled > a few releases when those were not met. But it's only a few years later when > I became a release manager and realised that I could potentially act > maliciously and modify the packages and .... no-one would notice - we > introduced source provenance check first and reproducible packages after that > realisation. > > Or maybe I am exaggerating, and it's "obvious enough" that we do not have to > state it? > > I'd love to hear what others think here. And I am happy to provide a concrete > proposal to the policy and do some advocacy for it, if others think it is > needed as well. > > J. > > > [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor > [2] https://www.apache.org/legal/release-policy.html > [3] https://infra.apache.org/release-distribution.html#sigs-and-sums > --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
