On Sat, Mar 30, 2024 at 09:20:28AM -0700, Carlos Rodriguez-Fernandez wrote:
I like the idea of the security path as well, where all packages in
that
path have upstream subject to higher security standards (that means helping
them to achieve it as well), and greater defense downstream in any way
possible.
Two things that came to mind I shared in another channel:
* no binary blobs in the upstream, or no blob referred to in the source
built, or referred to in the build tools
I think there's some useful points here, but this would need to be
qualified and/or made more flexible to be applied.
For example, systemd repo has fuzzer case files, which are a mix of
text, mojibake, and actual binary protocol samples. For example, dhcp
input packets, dns packets. There are also other ~binary test files,
for example corrupted journal files.
The tests are defined via meson.build, so those files are "referred to
in the build tools", and would not be allowed by the above definition.
But if we dropped those, we'd lose very valuable testing of the codebase.
* diffoscope should show no difference except file stats between the
tar.gz
being pulled by the spec, and the source brought with a git clone.
Here, OTOH, I'd just say that the tarball generated from a git clone
should be bit-identical to the tar.gz pulled in by the spec.
Both things could be automated with tools.
Zbyszek