4 ms·

That was twelve years ago. Do you think equally-bad bugs haven’t made it into upstream projects directly? Hell, many downstream patches exist to fix security b

That was twelve years ago. Do you think equally-bad bugs haven’t made it into upstream projects directly? Hell, many downstream patches exist to fix security bugs.

lmm 6y ago
> That was twelve years ago. It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. > Do you think equally-bad bugs haven’t made it into upstream projects directly? Honestly, I can't think of a single equally-bad bug in "normal" code, only in medical devices / industrial controllers / etc.. Cloudbleed wasn't this bad. Bumblebee deleting /usr wasn't this bad. It really was a uniquely awful bug.
- deknos 6y ago
  > It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? like with the example of phonehome features? arch and other distros are only possible, because for a long time, debian and other distros kept nagging the upstream authors for missing features or "nonfeatures". if debian wouldn't exist, i bet, arch had to patch much more itself.
  - lmm 6y ago
    I agree that patching upstream sources is sometimes necessary. I think Debian is overly aggressive about it (hypocritically so in places: they will patch upstream to comply with the FHS, but won't change their own packaging to comply with the LSB). More to the point, I think patching security-critical packages needs to be treated as a special case and subject to appropriate review (as many other distributions do).
  - BlackFingolfin 6y ago
    > It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. Once a user pointed this out to me, the next release fixed the underlying issue in a better way. After years in which the Debian folks didn't file an issue or report the problem in any way that I could tell. Mind you, Debian is not alone in this, it happens with other distros, too. And to be fair, I think this rather depends a lot on the downstream package maintainer; I've witnessed this with other projects where they were quite good in interacting with upstream to get something sorted out. I am not really sure if any policy Debian/Fedora/... could enact would really help with it; people can (accidentally or intentionally) ignore them.
    - gspr 6y ago
      > Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. In my experience it's rather uncommon for a DD not to contact upstream. Would you mind sharing the package name and vulnerability so I and others can learn what happened?
      - ldarby 6y ago
        If we're still talking about the Debian SSH key bug in 2008, here is the Debian bug (from 2006) that led to the security issue, which was discovered in 2008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516. Upstream was contacted about it: https://marc.info/?t=114651088900003&r=1&w=2 https://marc.info/?t=114651088900003&r=1&w=2
    - deknos 6y ago
      > Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. Once a user pointed this out to me, the next release fixed the underlying issue in a better way. After years in which the Debian folks didn't file an issue or report the problem in any way that I could tell. the maintainer made an error there. did you open a bugreport that you fixed it so the patch is not necessary? > And to be fair, I think this rather depends a lot on the downstream package maintainer; I've witnessed this with other projects where they were quite good in interacting with upstream to get something sorted out. I am not really sure if any policy Debian/Fedora/... could enact would really help with it; people can (accidentally or intentionally) ignore them. yeah and that's the point. people in this thread (not you as far as i see) say they do not trust debian because of this, but other distributors and packagers? do they have technical or organisatorial fences for avoiding such mishaps? if not, then other distributions are as problematic as debian, even arch. debian did a whole lotta good for Free software and i really start to dislike how people shit on the project (again not you).
mrslave 6y ago
I also haven't used Debian since. No, we are not naive as to the presence of security related bugs elsewhere (e.g. Heartbleed). Just a lot of reputation was lost. It was interesting because the cause was a patch crafted to satisfy a static analysis tool they insisted on applying to every package, which demonstrated their want to go above and beyond with respect to quality. Kudos to Debian in that regard. But a blindly applied policy, and bad judgement in disabling some cryptographic initialization code, caused a terrible bug. I wonder if this is less of an issue today because of well defined kernel interfaces for getting "good" random numbers (i.e. cryptographically suitable). I'm sure the devil is in the details, and OpenSSH's support for unpopular systems means intentional use of uninitialized variables is still in the code base. It's all very impressive to an outsider who knows enough not to tell cryptographers how to do their job.
- unixhero 6y ago
  Which Linux distrib do you prefer?
  - mrslave 6y ago
    Good question without an easy answer. I was a long-term Gentoo user but recently dumped it for NixOS. Colleagues were pushing it and so far I'm happy. Much less compiling and manual configuration which is what was driving me crazy about Gentoo. It took rather little effort to get the system in a state that feels very comfortable. But my needs have changed over time too, so this isn't strictly my opinion on what is best. More than a decade ago a programmer friend got Ubuntu running on a second hand desktop for a rather computer illiterate arts & letters student. He was able to navigate the GUI like any other system, and it had Firefox, OpenOffice, and mplayer. I knew then that Linux is a perfectly fine desktop OS. And now we're back to using Debian of a sort. ;-)
- lloydatkinson 6y ago
  > I also haven't used Debian since. I stopped using Debian when its ridiculous "free" purely ideological approach to software actually caused me issues. I needed to install Debian on a relatively old laptop a few years ago. It had all "mainstream" hardware. It's WiFi adapter was an Intel one (and a very common/popular one at the time), but it was one that wasn't open source. How did Debian approach this? It's installer gave me a not very subtle passive aggressive message telling me that although they have the drivers for the device, it was not going to install them... because the ISO did not include them. With no working WiFi, it of course could not connect to the internet to download them! Worse still, turns out that even if it had connected to the internet it wouldn't have downloaded and installed them anyway. I found this out because I managed to use an Ethernet connection. Completely stupid and frustrating and it felt like I was being blamed as if it was my fault. Installed Ubuntu, included the drivers, connected to WiFi during the installation. I have not used Debian on anything since.
apexalpha 6y ago
People who run Arch want this to happen. It validates their hobby-like approach to their OS.
- MrDresden 6y ago
  Could you elaborate on what you mean?
  - apexalpha 6y ago
    In my job we have 100+ people who run Linux as their main OS. Most run Ubuntu or Debian, and a few run Arch. And every few weeks someone mentions again how something broke, and they need to spend some time fixing it. I think the last one was VMWare not working on a kernel yet. Arch requires more time to maintain, and more manual maintenance. So in order to justify that extra spent time a lot of times they will bring up minor stuff that happens in Debian/Ubuntu, like this bug from 12 years ago, in order to justify running Arch, which is more of a "learn Linux" hobby.
    - gruelsandwich 6y ago
      In my experience, the "learn Linux"-part of using Arch is the installing/setup process. Over the past three years, I have had things break perhaps three times. All of them were either my own fault (outdatet package) or warned about through Arch News (which I didn't bother to check because it is only necessary a couple of times a year) That being said, running Arch on a computer that you need to be working at all time, might not be a good idea for professional reasons. However, I think you are essensially making a similiar argument for Arch, as they are making for the Debian bug.
    - bjoli 6y ago
      I was bitten by the rolling release arch many times on Arch Linux ARM. The last straw was when they decided to move the configuration directory for openVPN, which meant it just failed to start up, meaning I could not SSH into it. I had to retrieve it to debug it, costing me hours of lifetime I would rather have done something else with. I learned my lesson. From now on it is boring LTS distros only, and guix for things in userland where I want up to date things.

That was twelve years ago. Do you think equally-bad bugs haven’t made it into upstream projects directly? Hell, many downstream patches exist to fix security bugs.

lmm 6y ago

> That was twelve years ago. It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. > Do you think equally-bad bugs haven’t made it into upstream projects directly? Honestly, I can't think of a single equally-bad bug in "normal" code, only in medical devices / industrial controllers / etc.. Cloudbleed wasn't this bad. Bumblebee deleting /usr wasn't this bad. It really was a uniquely awful bug.

deknos 6y ago
> It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? like with the example of phonehome features? arch and other distros are only possible, because for a long time, debian and other distros kept nagging the upstream authors for missing features or "nonfeatures". if debian wouldn't exist, i bet, arch had to patch much more itself.
- lmm 6y ago
  I agree that patching upstream sources is sometimes necessary. I think Debian is overly aggressive about it (hypocritically so in places: they will patch upstream to comply with the FHS, but won't change their own packaging to comply with the LSB). More to the point, I think patching security-critical packages needs to be treated as a special case and subject to appropriate review (as many other distributions do).
- BlackFingolfin 6y ago
  > It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. Once a user pointed this out to me, the next release fixed the underlying issue in a better way. After years in which the Debian folks didn't file an issue or report the problem in any way that I could tell. Mind you, Debian is not alone in this, it happens with other distros, too. And to be fair, I think this rather depends a lot on the downstream package maintainer; I've witnessed this with other projects where they were quite good in interacting with upstream to get something sorted out. I am not really sure if any policy Debian/Fedora/... could enact would really help with it; people can (accidentally or intentionally) ignore them.
  - gspr 6y ago
    > Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. In my experience it's rather uncommon for a DD not to contact upstream. Would you mind sharing the package name and vulnerability so I and others can learn what happened?
    - ldarby 6y ago
      If we're still talking about the Debian SSH key bug in 2008, here is the Debian bug (from 2006) that led to the security issue, which was discovered in 2008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516. Upstream was contacted about it: https://marc.info/?t=114651088900003&r=1&w=2 https://marc.info/?t=114651088900003&r=1&w=2
  - deknos 6y ago
    > Well, as one of those upstream authors whose code was patched: I was never contacted about it, so I never knew there was a requirement to be met, and so they carried around a bad patch for years, about which I knew nothing. Once a user pointed this out to me, the next release fixed the underlying issue in a better way. After years in which the Debian folks didn't file an issue or report the problem in any way that I could tell. the maintainer made an error there. did you open a bugreport that you fixed it so the patch is not necessary? > And to be fair, I think this rather depends a lot on the downstream package maintainer; I've witnessed this with other projects where they were quite good in interacting with upstream to get something sorted out. I am not really sure if any policy Debian/Fedora/... could enact would really help with it; people can (accidentally or intentionally) ignore them. yeah and that's the point. people in this thread (not you as far as i see) say they do not trust debian because of this, but other distributors and packagers? do they have technical or organisatorial fences for avoiding such mishaps? if not, then other distributions are as problematic as debian, even arch. debian did a whole lotta good for Free software and i really start to dislike how people shit on the project (again not you).

mrslave 6y ago

I also haven't used Debian since. No, we are not naive as to the presence of security related bugs elsewhere (e.g. Heartbleed). Just a lot of reputation was lost. It was interesting because the cause was a patch crafted to satisfy a static analysis tool they insisted on applying to every package, which demonstrated their want to go above and beyond with respect to quality. Kudos to Debian in that regard. But a blindly applied policy, and bad judgement in disabling some cryptographic initialization code, caused a terrible bug. I wonder if this is less of an issue today because of well defined kernel interfaces for getting "good" random numbers (i.e. cryptographically suitable). I'm sure the devil is in the details, and OpenSSH's support for unpopular systems means intentional use of uninitialized variables is still in the code base. It's all very impressive to an outsider who knows enough not to tell cryptographers how to do their job.

unixhero 6y ago
Which Linux distrib do you prefer?
- mrslave 6y ago
  Good question without an easy answer. I was a long-term Gentoo user but recently dumped it for NixOS. Colleagues were pushing it and so far I'm happy. Much less compiling and manual configuration which is what was driving me crazy about Gentoo. It took rather little effort to get the system in a state that feels very comfortable. But my needs have changed over time too, so this isn't strictly my opinion on what is best. More than a decade ago a programmer friend got Ubuntu running on a second hand desktop for a rather computer illiterate arts & letters student. He was able to navigate the GUI like any other system, and it had Firefox, OpenOffice, and mplayer. I knew then that Linux is a perfectly fine desktop OS. And now we're back to using Debian of a sort. ;-)
lloydatkinson 6y ago
> I also haven't used Debian since. I stopped using Debian when its ridiculous "free" purely ideological approach to software actually caused me issues. I needed to install Debian on a relatively old laptop a few years ago. It had all "mainstream" hardware. It's WiFi adapter was an Intel one (and a very common/popular one at the time), but it was one that wasn't open source. How did Debian approach this? It's installer gave me a not very subtle passive aggressive message telling me that although they have the drivers for the device, it was not going to install them... because the ISO did not include them. With no working WiFi, it of course could not connect to the internet to download them! Worse still, turns out that even if it had connected to the internet it wouldn't have downloaded and installed them anyway. I found this out because I managed to use an Ethernet connection. Completely stupid and frustrating and it felt like I was being blamed as if it was my fault. Installed Ubuntu, included the drivers, connected to WiFi during the installation. I have not used Debian on anything since.

apexalpha 6y ago

People who run Arch want this to happen. It validates their hobby-like approach to their OS.

MrDresden 6y ago
Could you elaborate on what you mean?
- apexalpha 6y ago
  In my job we have 100+ people who run Linux as their main OS. Most run Ubuntu or Debian, and a few run Arch. And every few weeks someone mentions again how something broke, and they need to spend some time fixing it. I think the last one was VMWare not working on a kernel yet. Arch requires more time to maintain, and more manual maintenance. So in order to justify that extra spent time a lot of times they will bring up minor stuff that happens in Debian/Ubuntu, like this bug from 12 years ago, in order to justify running Arch, which is more of a "learn Linux" hobby.
  - gruelsandwich 6y ago
    In my experience, the "learn Linux"-part of using Arch is the installing/setup process. Over the past three years, I have had things break perhaps three times. All of them were either my own fault (outdatet package) or warned about through Arch News (which I didn't bother to check because it is only necessary a couple of times a year) That being said, running Arch on a computer that you need to be working at all time, might not be a good idea for professional reasons. However, I think you are essensially making a similiar argument for Arch, as they are making for the Debian bug.
  - bjoli 6y ago
    I was bitten by the rolling release arch many times on Arch Linux ARM. The last straw was when they decided to move the configuration directory for openVPN, which meant it just failed to start up, meaning I could not SSH into it. I had to retrieve it to debug it, costing me hours of lifetime I would rather have done something else with. I learned my lesson. From now on it is boring LTS distros only, and guix for things in userland where I want up to date things.