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