New supply-chain security tool: backseat-signed

kpcyrd kpcyrd at archlinux.org
Sat Apr 6 13:54:51 UTC 2024


On 4/6/24 1:42 PM, Adrian Bunk wrote:
> You cannot simply proclaim that some git tree is the preferred form of
> modification without shipping said git tree in our ftp archive.
> 
> If your claim was true, then Debian and downstreams would be violating
> licences like the GPL by not providing the preferred form of modification
> in the archive.

I'm obviously not a lawyer, but I do think this is the case. Quoting 
from GPL-3.0:

 > The “source code” for a work means the preferred form of the work for 
making modifications to it. “Object code” means any non-source form of a 
work.

autotools pre-processed source code is clearly not "the preferred form 
of the work for making modifications", which is specifically what I'm 
saying Debian shouldn't consider a "source code input" either, to 
eliminate this vector for underhanded tampering that Jia Tan has used.

If we can force a future Jia Tan to commit their backdoor into git (for 
everybody to see) I consider this a win.

 > The “Corresponding Source” for a work in object code form means all 
the source code needed to generate, install, and (for an executable 
work) run the object code and to modify the work, including scripts to 
control those activities.

The GPL is big on "if you ship object files, the source code for them 
better also be available".

The GPL specifically allows me to have private forks, as long as I'm not 
publicly distributing binaries. If I do distribute binaries, I need to 
also publish the source code I derived them from.

Again: The source code needed to build the binaries.

It does not require me to disclose some version control graph, but I do 
need to provide all source code that goes into the build (which is what 
.orig.tar.xz is supposed to be).

A "source code build process" is clearly just the build process in a 
trenchcoat.

cheers,
kpcyrd


More information about the rb-general mailing list