On 30/03/24 01:21, Antonio Russo wrote:
3. Have tooling that automatically checks the sanitized sources against
the development RCSs.
git-buildpackage and pristine-tar can be used for that.
4. Look unfavorably on upstreams without RCS.
And look unfavorably on Debian packages without VCS. And, in addition:5. Require something like tag2upload to create new releases of Debian packages.
For too many core packages there is an opaque "something happens on the Debian maintainer laptop" step that has no place in 2024. We have no idea how many Debian DDs/DMs machiens have been compromised because of this attack. (Hopefully zero.) Any future upload of source debs may, in principle, contain malicious code.
The workflow for Debian packages has already gone from: 1. new upstream release; 2. something happens on the DD/DM machine;3. the DD/DM uploads two non-reviewed-in-practice blobs (source deb, binary deb) to unstable.
to: 1. new upstream release; 2. something happens on the DD/DM machine;3. the DD/DM uploads a non-reviewed-in-practice blob (source deb) to the buildd;
4. the buildd compiles the source deb into the binary deb;5. the buildd uploads a non-reviewed-in-practice blob (binary deb) to unstable.
This change moved a lot of trust from the hands (and machines) of a myriad of DDs/DMs into a handful of closely guarded build machines. A compromised gcc on the DD/DM machine is no longer a problem. But a compromised tar/dpkg/debhelper still is.
Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the new release;4. the buildd creates and uploads the non-reviewed-in-practice blobs "source deb" and "binary deb" to unstable.
This change would have three advantages:* Make the whole process happen outside the DD/DM computer, so it becomes more public and easier to review (commits vs debs), removing many chances for compromises.
* Close two specific attack vectors (hiding code in upstream release tarballs and in source debs) that have always existed and for one of which we have now proof of exploitation.
* Force attackers to do their work under public scrutiny, raising the complexity and the cost of carrying out an attack.
Yes, such a workflow will not stop many other attack vectors, but at least _these_ attack vectors will be stopped.
Regards, -- Gioele Barabucci
