3 ms·

> It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical softwa

by 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).

by deknos 6y ago

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).