Yet another issue due to nonsensical Debian packaging policies. Debian should just stop wasting time applying random patches or modifying packages, if upstream is doing something there's probably a good reason for that.
I didn't go there at any point while writing the article, because, for a Linux distro (i.e. something that tries to be all things to all people), I think Debian does a great job, and the packaging policy is a net positive, by a wide margin. These things happen sometimes, and Chris Lamb (the package maintainer and Debian / reproducible builds extraordinaire), as well as both the Debian and Ubuntu teams, handled them very well.
When running large scale production services, the best practice is building your own image, perhaps starting minimal Debian or Alpine core, using automation, and the tech giants have settled on statically linked binaries a while ago, so Debian packaging "idiosyncrasies" should not apply anyways.
Distributions continuously patch packages. It's necessary to be able to ship a working, integrated distribution at all. It's also necessary because users expect some level of consistency and integration between components, and distributions are the spaces where that can be achieved. Usually these achievements then get upstreamed so it's easy to forget about their origin. There's also the cases where distribution users just fundamentally disagree with upstream policy and use their ability to change Free Software to make it happen - such as the disabling of auto-updates in distribution packages coming outside the distribution packaging system, or the disabling of [opt-out] telemetry.
So there are many good reasons distributions patch. It's not reasonable to paint them all with the same brush. If you want to credibly criticize this, you need to be more specific.
This isn't the only time Debian has introduced a serious security vulnerability by changing things in packages. The most notable prior example that comes to mind is CVE-2008-0166.
The real bug here is not having a test for this, or not running the tests as part of the packaging process. We should not have situations where packages are so sensitive that a small change to them should be considered unsafe. Open Source is pointless if your source is regarded as immutable. If there is a subtle detail like this (and sometimes it's unavoidable), it should be covered by a test so that ensuring the end result is "ok" is nothing more than seeing the tests pass.
I'm not going to weigh in on which party should be responsible for that test.
Unfortunately, Debian will sometimes also patch the package to remove failing tests, not understanding that it is a security issue. This is not the first time this has happened.
This is also sometimes unavoidable because not all test suites are built very robustly. One often comes across projects with test suites that the author only intended for their own use and doesn't care if it fails on other peoples systems.
Maybe upstream shouldn't make their security measures so fragile that everyone downstream has to resign themselves to not touching anything. Open source software is supposed to be modified and adapted.
Is this Lua sandboxing really a good idea? It it robust? It didn't work out well for Java, which removed the SecurityManager feature recently. Python gave up on attempts at sandboxing many decades ago.
Comments
Yet another issue due to nonsensical Debian packaging policies. Debian should just stop wasting time applying random patches or modifying packages, if upstream is doing something there's probably a good reason for that.
I didn't go there at any point while writing the article, because, for a Linux distro (i.e. something that tries to be all things to all people), I think Debian does a great job, and the packaging policy is a net positive, by a wide margin. These things happen sometimes, and Chris Lamb (the package maintainer and Debian / reproducible builds extraordinaire), as well as both the Debian and Ubuntu teams, handled them very well.
When running large scale production services, the best practice is building your own image, perhaps starting minimal Debian or Alpine core, using automation, and the tech giants have settled on statically linked binaries a while ago, so Debian packaging "idiosyncrasies" should not apply anyways.
Distributions continuously patch packages. It's necessary to be able to ship a working, integrated distribution at all. It's also necessary because users expect some level of consistency and integration between components, and distributions are the spaces where that can be achieved. Usually these achievements then get upstreamed so it's easy to forget about their origin. There's also the cases where distribution users just fundamentally disagree with upstream policy and use their ability to change Free Software to make it happen - such as the disabling of auto-updates in distribution packages coming outside the distribution packaging system, or the disabling of [opt-out] telemetry.
So there are many good reasons distributions patch. It's not reasonable to paint them all with the same brush. If you want to credibly criticize this, you need to be more specific.
Isn't a major selling point of Arch that it works fine without patching packages?
I think it would be more accurate to say that Arch tends to do less patching than other distros, sometimes even none but not always.
Arch patches Redis, although not for lua. https://github.com/archlinux/svntogit-community/blob/package...
Because all of the issues they've genuinely fixed, security and otherwise, are meaningless.
Or are you just basing this on <bad thing> happened, thus all other cases (hundred of thousands of patches) are wrong?
This isn't the only time Debian has introduced a serious security vulnerability by changing things in packages. The most notable prior example that comes to mind is CVE-2008-0166.
That's a notable prior example from 14 years ago. I'm not sure you're making a strong argument here!
It's still relevant for Web PKI work.
How is it still relevant? Even if certs made with a vulnerable version weren't revoked at the time, wouldn't they would have been rotated by now?
Another similar one (perhaps worse!) from the same era: https://jblevins.org/log/ssh-vulnkey
Isn't that the same one?
Ah, yes, good catch!
The real bug here is not having a test for this, or not running the tests as part of the packaging process. We should not have situations where packages are so sensitive that a small change to them should be considered unsafe. Open Source is pointless if your source is regarded as immutable. If there is a subtle detail like this (and sometimes it's unavoidable), it should be covered by a test so that ensuring the end result is "ok" is nothing more than seeing the tests pass.
I'm not going to weigh in on which party should be responsible for that test.
Unfortunately, Debian will sometimes also patch the package to remove failing tests, not understanding that it is a security issue. This is not the first time this has happened.
This is also sometimes unavoidable because not all test suites are built very robustly. One often comes across projects with test suites that the author only intended for their own use and doesn't care if it fails on other peoples systems.
If you think the patches are random, you must be missing something.
If upstream developers took good care of their security Linux distributions would not have to do all the patching and dependency unbundling.
Maybe upstream shouldn't make their security measures so fragile that everyone downstream has to resign themselves to not touching anything. Open source software is supposed to be modified and adapted.
Is this Lua sandboxing really a good idea? It it robust? It didn't work out well for Java, which removed the SecurityManager feature recently. Python gave up on attempts at sandboxing many decades ago.