Maytham Alsudany <maytha8thedev@gmail.com> writes: > Hi Simon, > > On Sat, 2024-03-30 at 09:48 +0100, Simon Josefsson wrote: >> Maytham Alsudany <maytha8thedev@gmail.com> writes: >> >> > https://salsa.debian.org/go-team/packages/golang-github-go-git-go-git-fixtures >> >> I looked at this update, and one of the proposed changes is to include >> all of the pre-generated stuff from here: > > Previous versions of the package also include this test data. Not in the binary: https://packages.debian.org/sid/all/golang-github-go-git-go-git-fixtures-dev/filelist >> https://github.com/go-git/go-git-fixtures/tree/master/data >> >> directly into the installed Debian package. Given the recent xz fiasco, >> I have doubts that this is a good idea -- there is a bunch of >> pre-generated compressed git repositories in that directory, and I don't >> see any way to re-create them from scratch. They seem to have been >> manually curated by some developer in the past and then compressed and >> uploaded, somewhat similar to how the xz problem happened. > > They can be decoded though to reveal the source; each tgz archive contains a > bare git repo, which can be converted into a normal git repo using the method > outlined at [1]. > > We can regenerate them manually, but it will take a bit of time to do so. What > I'm thinking is decompressing each repo archive, and converting the commits > into a series of patches, accompanied by a shell script or something that can > turn the patches into a Git repo with the correct branches, tags, etc. > > Alternatively (in the long-term), we can drop the whole fixtures package as you > suggested, and rewrite the tests in go-git so that Git is used to generate the > test repos in the first place (using a Makefile or 'go generate'). Would this be an upstream wishlist bug report? Seems like it is not our job as packagers to implement this, but should be done in upstream. >> 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. > >> Of course, I only did a cursory review, so I may have misunderstood how >> this project works and the relevance of these files. > > AFAIK, you're right; the only purpose for these files is for tests in go-git. > Removing them isn't going to impact the functionality of go-git. Until the fixtures can be reproducibly re-created from some script, I think the safest is to disable use of them in go-git as you suggest. I'm not sure how important it is to RM go-git-fixtures though, maybe this will be fixed upstream eventually, and then it does make sense to include it so that go-git has good test coverage. /Simon > > Kind regards, > Maytham > > [1]: https://stackoverflow.com/a/10637882 >
Attachment:
signature.asc
Description: PGP signature