4 ms·

> 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 a

> 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).
- lmm 6y ago
  > other distributors and packagers? do they have technical or organisatorial fences for avoiding such mishaps? Many distributions have a dedicated security team that has to sign off any patches to security-critical software. Debian's position is that they do not have the resources for such a team, which is fair enough, but IMO the conclusion should be that they don't have the resources to be applying their own patches to security-critical software. More subjectively I get the sense that Debian packagers patch more aggressively and generally think the Debian way of things is better. This isn't completely groundless: there's a lot of very high quality engineering in Debian, and for a long time their package management was head and shoulders above others, especially if we're talking about C programs/libraries where upstream dependency management is very weak. But it's also made for a culture where packagers think they know better than upstream maintainers, and an approach that ends up conflicting quite a bit with newer languages where there is high-quality dependency management in the upstream builds.
  - cutemonster 6y ago
    > Many distributions have a dedicated security team Which are some of those distros? (I'd consider using myself in the future)
  - eeZah7Ux 6y ago
    > Many distributions have a dedicated security team that has to sign off any patches to security-critical software This is false. Debian has a security team and it's way more active than most distributions. > But it's also made for a culture where packagers think they know better than upstream maintainers Yes and for good reasons.
bityard 6y ago
You seem to be _almost_ implying that the packager maintainer had some sort of obligation to notify you that your software was being shipped with Debian? And also that you didn't know about it for years? On the flip side of the coin, there are plenty of open source authors who release their work into the wild and refuse to support or even engage with downstream packagers because they see any other distribution or use of their work as Not Their Problem. And they're not really wrong, building a supportive community around a useful project is totally optional after all. Between the constant stream of version bumps, security updates, patching, bug triaging, and user support, distribution maintenance seems to be the most thankless job in the open source world.

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

lmm 6y ago
> other distributors and packagers? do they have technical or organisatorial fences for avoiding such mishaps? Many distributions have a dedicated security team that has to sign off any patches to security-critical software. Debian's position is that they do not have the resources for such a team, which is fair enough, but IMO the conclusion should be that they don't have the resources to be applying their own patches to security-critical software. More subjectively I get the sense that Debian packagers patch more aggressively and generally think the Debian way of things is better. This isn't completely groundless: there's a lot of very high quality engineering in Debian, and for a long time their package management was head and shoulders above others, especially if we're talking about C programs/libraries where upstream dependency management is very weak. But it's also made for a culture where packagers think they know better than upstream maintainers, and an approach that ends up conflicting quite a bit with newer languages where there is high-quality dependency management in the upstream builds.
- cutemonster 6y ago
  > Many distributions have a dedicated security team Which are some of those distros? (I'd consider using myself in the future)
- eeZah7Ux 6y ago
  > Many distributions have a dedicated security team that has to sign off any patches to security-critical software This is false. Debian has a security team and it's way more active than most distributions. > But it's also made for a culture where packagers think they know better than upstream maintainers Yes and for good reasons.

bityard 6y ago

You seem to be _almost_ implying that the packager maintainer had some sort of obligation to notify you that your software was being shipped with Debian? And also that you didn't know about it for years? On the flip side of the coin, there are plenty of open source authors who release their work into the wild and refuse to support or even engage with downstream packagers because they see any other distribution or use of their work as Not Their Problem. And they're not really wrong, building a supportive community around a useful project is totally optional after all. Between the constant stream of version bumps, security updates, patching, bug triaging, and user support, distribution maintenance seems to be the most thankless job in the open source world.