Blobs in self-tests

[jas4711]

Hi! This came up during debian copyright review of files in sbctl, see https://salsa.debian.org/newgateway-team/reviews/-/issues/30

At least the following binaries are stored in the git repository:

• tests/bzImage
• tests/binaries/test.pecoff
• tests/ovmf/OVMF_VARS.fd
• tests/ovmf/keys/initramfs.cpio

How where they created? What's the licensing terms? Pointers to source code?

I understand this is a boring request, but given xz I think feedback like this have some weight.

Some simple ways to resolve this:

1. Remove the binaries from git, downloading them during self-check phase. Then at least the source repository isn't tainted by these blobs.

2. Move binaries to a separate e.g. sbctl-test repository, and run self-tests there. May be combined with 1).

3. Provide build instructions and source code for re-building those binaries (sounds like work).

4. The debian package shouldn't use upstream source code without filtering these blobs. I suppose this is the simple approach for us, but it just hides the concern which IMHO warrant some upstream consideration.

Thanks,
Simon

[Foxboron]

I slightly suspect some of these are no longer needed, I've been bad at cleaning up the test suite. But there are things like tests/bzImage which is there purely for convenience as I don't want to compile the kernel nor deal with peoples distro kernels for the test suite. Not sure what I'll be doing with that.

[jas4711]

What do you think about removing them from git, and adding some script that download the blob from an earlier git commit on github.com? That at least make the source code not contain blobs, and we can disable/ignore the script that download things for our packaging. It would still work if you make use of it in GitHub Actions or similar.

[Foxboron]

I've removed the initramfs.cpio and OVMF_VARS.fd as both files where mistakes.

I'm not going to spend time on removing bzImage now, but I believe the file is from https://github.com/hugelgupf/vmtest as I was bootstrapping the vm test setup using their files.

The test.pecoff should just be an effectively empty PE/COFF binary, but I do not recall where I made it. It's probably just some handmade C code I strapped down until sbctl would touch it. I'll see if I deal with it later, but it's not high on my priority list.