AndresFreundTecI accidentally found a security issue while benchmarking postgres changes.
If you run debian testing, unstable or some other more "bleeding edge" distribution, I strongly recommend upgrading ASAP.
I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.
Really required a lot of coincidences.
Glyph@AndresFreundTec I feel both confident and also kind of queasy when saying this: it seems extremely likely that this is not the first time something like this has happened, it's just the first time we have been lucky enough to notice.
LisPi@glyph @AndresFreundTec That is true.
Binary artifacts have no business existing in Free Software (or near-binary considering how auditable pre-generated config scripts end-up being). The way it was compromised in this case is almost certain to have happened before and reminds me of the SourceForge malware debacle (so arguably that's another famous example of it happening before).
I"m not sure if many other projects do like Guix and record the checksum of the whole repository so as to ensure reproducibility purely from source.
Binary artifacts have no business existing in Free Software (or near-binary considering how auditable pre-generated config scripts end-up being). The way it was compromised in this case is almost certain to have happened before and reminds me of the SourceForge malware debacle (so arguably that's another famous example of it happening before).
I"m not sure if many other projects do like Guix and record the checksum of the whole repository so as to ensure reproducibility purely from source.
Marcelo Magallon@lispi314 @AndresFreundTec @glyph we have been using docker images for what? 10+ years now, and "everyone" seems OK with the fact that the vast majority of them are not reproducible because the corresponding dockerfile is not generally available.
@mem @glyph @AndresFreundTec That is incidentally one of the *many* reasons I don't use Docker or similar container infrastructure.
It is... unfortunately necessary to accept that some things aren't reproducible because the tooling fails to do it (Common Lisp implementations tend not to dump reproducible images, there are patches pending for a few of them but...). That being said, the reasonable answer in that scenario is to instead ensure that all of the inputs are identical and rebuild everything from source, as Guix does (or for Common Lisp to just run everything from source, as one should do anyway, compilation & caching, if any, should be transparently handled by the implementation).
And indeed, you *can* use this procedure with Guix to generate Docker images.
So for those images where the Dockerfile necessary to rebuild it from scratch isn't available? They're garbage and unusable.
It is... unfortunately necessary to accept that some things aren't reproducible because the tooling fails to do it (Common Lisp implementations tend not to dump reproducible images, there are patches pending for a few of them but...). That being said, the reasonable answer in that scenario is to instead ensure that all of the inputs are identical and rebuild everything from source, as Guix does (or for Common Lisp to just run everything from source, as one should do anyway, compilation & caching, if any, should be transparently handled by the implementation).
And indeed, you *can* use this procedure with Guix to generate Docker images.
So for those images where the Dockerfile necessary to rebuild it from scratch isn't available? They're garbage and unusable.