6 ms·

Yet another issue due to nonsensical Debian packaging policies. Debian should just stop wasting time applying random patches or modifying packages, if upstream

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.

b112 5y ago
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?
- josephcsible 5y ago
  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.
  - gmfawcett 5y ago
    That's a notable prior example from 14 years ago. I'm not sure you're making a strong argument here!
    - pgporada 5y ago
      It's still relevant for Web PKI work.
      - yjftsjthsd-h 5y ago
        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?
  - gunapologist99 5y ago
    Another similar one (perhaps worse!) from the same era: https://jblevins.org/log/ssh-vulnkey https://jblevins.org/log/ssh-vulnkey
    - josephcsible 5y ago
      Isn't that the same one?
      - gunapologist99 5y ago
        Ah, yes, good catch!
rlpb 5y ago
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.
- josephcsible 5y ago
  Isn't a major selling point of Arch that it works fine without patching packages?
  - chadcatlett 5y ago
    Arch patches Redis, although not for lua. https://github.com/archlinux/svntogit-community/blob/packages/redis/trunk/PKGBUILD#L27 https://github.com/archlinux/svntogit-community/blob/package...
  - yjftsjthsd-h 5y ago
    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.
deleted 5y ago
[deleted]
reginaldo 5y ago
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.
gspr 5y ago
If you think the patches are random, you must be missing something.
ptx 5y ago
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.
ris 5y ago
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.
- Jasper_ 5y ago
  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.
  - ris 5y ago
    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.
goodpoint 5y ago
If upstream developers took good care of their security Linux distributions would not have to do all the patching and dependency unbundling.

b112 5y ago

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?

josephcsible 5y ago
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.
- gmfawcett 5y ago
  That's a notable prior example from 14 years ago. I'm not sure you're making a strong argument here!
  - pgporada 5y ago
    It's still relevant for Web PKI work.
    - yjftsjthsd-h 5y ago
      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?
- gunapologist99 5y ago
  Another similar one (perhaps worse!) from the same era: https://jblevins.org/log/ssh-vulnkey https://jblevins.org/log/ssh-vulnkey
  - josephcsible 5y ago
    Isn't that the same one?
    - gunapologist99 5y ago
      Ah, yes, good catch!

rlpb 5y ago

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.

josephcsible 5y ago
Isn't a major selling point of Arch that it works fine without patching packages?
- chadcatlett 5y ago
  Arch patches Redis, although not for lua. https://github.com/archlinux/svntogit-community/blob/packages/redis/trunk/PKGBUILD#L27 https://github.com/archlinux/svntogit-community/blob/package...
- yjftsjthsd-h 5y ago
  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.

deleted 5y ago

[deleted]

reginaldo 5y ago

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.

gspr 5y ago

If you think the patches are random, you must be missing something.

ptx 5y ago

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.

ris 5y ago

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.

Jasper_ 5y ago
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.
- ris 5y ago
  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.

goodpoint 5y ago

If upstream developers took good care of their security Linux distributions would not have to do all the patching and dependency unbundling.