Hi everyone, (CC Praveen; we'd like your input please as you're the uploader) On Sat, 2024-03-30 at 13:06 +0100, Simon Josefsson wrote: > Nilesh Patra <nilesh@debian.org> writes: > > At this rate, we will end up pruning a bunch of stuff from Debian. I don't think it > > is wise to remove a package just because of paranoia without fact-checking. I would > > at least check with the upstream developer once. Just saying. Yes, I've been a bit hesitant with this. https://github.com/go-git/go-git-fixtures/issues/19 > I agree! I think my initial review came out too strong. I like an > incremental approach - file this as an upstream wishlist bug to improve > reproducing the included binary blobs. And we could file a wishlist > debian bug to analyze these binary blobs in case they turn out not to be > reproducible from source... I believe that is Debian policy for all > packages in main anyway. There is a lot of these pregenerated binary > blobs in Debian that are assumed to be possible to re-create from source > but rarely tested, as you say. This sounds like a discussion more suited for debian-devel. > > > > Dropping these files may mean we don't test as much of go-git that is > > > > possible to test, but the alternative that we create a vector to inject > > > > binaries with no source code into Debian seems worse. > > > > > > > > Could you modify this package to drop any files that we cannot re-create > > > > during the build? Maybe the entire package becomes useless, if so, then > > > > we should just remove it IMHO. > > > > > > RM bug filed. > > > > In such cases, you need to consult the uploader. Please never file RM bugs without taking > > permission from uploader or maintainer (if it is an individual) of a package. > > > > Do note that it has 2 reverse-depends, which need to be fixed before the removal happens, else > > they start to FTBFS. > > > > > $ reverse-depends golang-github-go-git-go-git-fixtures-dev -b > > > Reverse-Build-Depends > > > ===================== > > > * golang-github-go-git-go-git > > > * golang-github-jesseduffield-go-git > > Yeah I don't see the urgency in completing the RM now; more review and > discussion is better. I admit I was a bit rushed with the RM bug. Honestly, I think these tarballs are fine, because they can be decompressed to read their contents (unlike the xz binary blobs). I don't see any major problem with having this testdata stored in this format. AFAICS the only way to exploit this is through one of three ways: - A vulnerability in git - A vulnerability in tar/gunzip - A vulnerability in go-git or go-git-fixtures Go scripts Git, tar, and gunzip is outside of the scope of this problem, and go-git and go- git-fixtures source code is easily viewable. Additionally, the contents of these test repos aren't being executed, they're only being used to test different scenarios in Git. I believe the best course of action for now it to upload go-git and go-git- fixtures in their current state, and see what upstream thinks. If it is really necessary, then maybe an RC bug can be filed against go-git-fixtures to get it pulled from testing, and then the two go-git packages can be patched to follow suit (but I don't think this is a good idea). What are your thoughts? Kind regards, Maytham
Attachment:
signature.asc
Description: This is a digitally signed message part