Re: xz backdoor
On Mon, Apr 01, 2024 at 12:02:09PM +0200, Bastian Blank wrote:
> Hi
>
> On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > > What we can do unilaterally is to disallow vendoring those files.
> > These files are supposed to be vendored in release tarballs,
> > the sane approach for getting rid of such vendored files would
> > be to discourage tarball uploads to the archive and encourage
> > git uploads instead.
>
> I don't understand what you are trying to say. If we add a hard check
> to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> if the upload is a tarball or git.
xz also has > 600 LOC of legit own m4 code in m4/*,
and that's not unusual for packages using autoconf.
> > > Does it help? At least in the case of autoconf it removes one common
> > > source of hard to read files.
> > But I doubt every DD would be able to review the 2k LOC non-vendored
> > autoconf code in xz.
>
> But at least changes to this code are visible. In this case the changes
> to the m4 stuff did not exist in the somewhat reviewed repo, but just in
> the unreviewed tarballs.
There are many other ways how these unreviewed tarballs could be manipulated.
The root cause of the problem you want to solve is that the ftp team
permits uploading such unreviewed tarballs to our archive.
> Bastian
cu
Adrian
Reply to: