Security updates

[cedws]

I've had my eye on this tool for a while and just attended the talk at FOSDEM by @AkihiroSuda (thanks!)

I asked a question regarding security updates but some people were making noise so I couldn't hear the response 😅

In a standard unreproducible container build, people can unknowingly benefit from security updates at build time. Every build is guaranteed to have the most secure versions of the needed packages.

My concern is that using a lockfile for package versions means forgoing security updates. Of course, there's no way around this. It's impossible to install newer versions of packages and produce the same container with the same hash.

I was wondering the tool could have a feature to analyse a lockfile and say whether the packages inside it have available security updates. Then, we could run this in a CI pipeline and have the build fail if there are so that maintainers know a new lockfile with secure packages needs to be generated.

What are your thoughts?

[kpcyrd]

I think not using dependency lockfiles doesn't make the security issues go away, you're just not documenting which ones are present in the build you're distributing (assuming you're distributing pre-built images). :)

To fix the pre-built image you need to publish a new release that is actually built with the latest dependencies anyway, a dependency lockfile just makes this more explicit. It also makes it much more transparent to which version of your software users need to upgrade to be secure (until new bugs are discovered).

osv-scanner recently learned how to parse /lib/apk/db/installed, an internal file of the Alpine package manager that contains all installed package versions (this feature was merged to master but not yet released). I assume processing repro-get lockfiles wouldn't be much different. But note this is a very distro specific question and https://osv.dev/ only has data for Alpine and Debian.

[cedws]

I think not using dependency lockfiles doesn't make the security issues go away, you're just not documenting which ones are present in the build you're distributing (assuming you're distributing pre-built images). :)

This is accurate, but see below.

To fix the pre-built image you need to publish a new release that is actually built with the latest dependencies anyway, a dependency lockfile just makes this more explicit.

Yep. However, a lot of developers don't pay as much attention to security as they should and the only time they might get security fixes is by building a new container version for some unrelated reason. Using repro-get means losing this. Of course, we should encourage them to care about security and reproducibility. They might not consider this side effect without being told to.

osv-scanner recently learned how to parse /lib/apk/db/installed, an internal file of the Alpine package manager that contains all installed package versions (this feature was merged to master but not yet released).

This is cool. I've heard of tools for scanning container images that currently run on a cluster for example. I think it's even better to block insecure containers from reaching the registry if possible. Proactive instead of reactive.

[cedws]

Now that I think about it more, maybe this should not be a responsibility of repro-get. There are definitely CI tools out there already for blocking insecure containers from being pushed.

Maybe the best move is to just make this side effect more clear to users.

[kpcyrd]

I think to some degree it's also about respecting this disclaimer 😺

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED

I think some rando volunteer developer shouldn't be morally held liable to keep the dependency lockfile updated (it's very kind of them if they provide this as a free service of course!).

If I'm reading the documentation right you can resolve to the latest security patch level with this command:

repro-get hash update SHA256SUMS-amd64

If you explicitly want to:

• resolve to the latest system dependency patch level during a CI build
• publish bit-for-bit reproducible-from-source docker images

It could be sufficient to publish the updated SHA256SUMS-amd64 as a release artifact to allow me to reproduce it (assuming I know the right git commit too). :)

[cedws]

Sorry, I think I have explained myself poorly.

I am definitely not saying that this project is somehow liable for the mistakes or oversights of users. It's about making the tool nice to use and hard to misuse. Lots of projects have caveats - it's nice to be explicit about what they are if they can't be resolved. Even just a sentence in the README works.

I will close the issue since I don't think there's a clear resolution but I think there could be enhancements made. Feel free to reopen if you want.

[AkihiroSuda]

We have to have a GitHub Actions tool to keep the hash file up-to-date.

Eventually it is expected to be supported by Dependabot too.
(So we have to embed some metadata comments in the hash file? e.g., distro driver, file provider URLs?)

[cedws]

Awesome, thanks.