3 ms·

From the linked CVE page: Notes: Issue introduced with the Debian specific fix for CVE-2013-0337 / #701112 So Nginx users on non-Debian-based syste

by LukeShu 10y ago

From the linked CVE page: Notes: Issue introduced with the Debian specific fix for CVE-2013-0337 / #701112 So Nginx users on non-Debian-based systems don't need to worry.

vog 10y ago
It's not the first time that Debian-specific patches introduce large issues. The most prominent failure was the deeply flawed SSH key generation of the Debian-modified OpenSSH. This is a general problem, that almost inevitably happens if patches are developed by (non-upstream) people who do not have an intimate knowledge of the code. What's worse in the case of Debian and other distros is that they have no incentive to coordinate their patches with upstream. In particular, they do not need to convince upstream for inclusion. This is quite risky from a Q/A point of view. I wonder when this issue will appear in enterprise distros (RHEL, SLES, etc.) as well, where the situation is even worse. These distros try to support package versions which are way older than Debian/Stable ever got, backporting patches to versions which aren't even interesting to upstream anymore, so they couldn't receive good feedback from upstream even if they suddenly decided to care about upstream's opinion.
- avian 10y ago
  > What's worse in the case of Debian and other distros is that they have no incentive to coordinate their patches with upstream. They do have an incentive: patches against upstream need to be maintained. Maintainer has much less work if any patches are included upstream. I can't speak for other distros, but in my experience many Debian maintainers will strongly oppose including distro-specific patches in their packages without a very good reason.
  - vog 10y ago
    > They do have an incentive: patches against upstream need to be maintained You are right. However, this only means they have an incentive to push patches to upstream _in hindsight_. That's is better than nothing, but still happens after the fact, when the damage is done and the defect distributed to the users. As far as I know, they have no incentive to _wait_ for their patches to be included in upstream. > many [...] maintainers will strongly oppose including distro-specific patches in their packages without a very good reason. Well, fixing security issues is often seen as a "very good reason", completely ignoring that an incomplete and/or errorneous security fix may do more harm than good, and meanwhile provides the users with a false sense of security.
    - feld 10y ago
      This is precisely why I'm against the Linux style "freeze software at version X" methodology.
      - chme 10y ago
        What does the kernel has to do with this? That is an issue some distributions introduced and they have to deal with it or you should choose one that does a rolling release.

by LukeShu 10y ago

From the linked CVE page: Notes: Issue introduced with the Debian specific fix for CVE-2013-0337 / #701112 So Nginx users on non-Debian-based systems don't need to worry.

vog 10y ago

It's not the first time that Debian-specific patches introduce large issues. The most prominent failure was the deeply flawed SSH key generation of the Debian-modified OpenSSH. This is a general problem, that almost inevitably happens if patches are developed by (non-upstream) people who do not have an intimate knowledge of the code. What's worse in the case of Debian and other distros is that they have no incentive to coordinate their patches with upstream. In particular, they do not need to convince upstream for inclusion. This is quite risky from a Q/A point of view. I wonder when this issue will appear in enterprise distros (RHEL, SLES, etc.) as well, where the situation is even worse. These distros try to support package versions which are way older than Debian/Stable ever got, backporting patches to versions which aren't even interesting to upstream anymore, so they couldn't receive good feedback from upstream even if they suddenly decided to care about upstream's opinion.

avian 10y ago
> What's worse in the case of Debian and other distros is that they have no incentive to coordinate their patches with upstream. They do have an incentive: patches against upstream need to be maintained. Maintainer has much less work if any patches are included upstream. I can't speak for other distros, but in my experience many Debian maintainers will strongly oppose including distro-specific patches in their packages without a very good reason.
- vog 10y ago
  > They do have an incentive: patches against upstream need to be maintained You are right. However, this only means they have an incentive to push patches to upstream _in hindsight_. That's is better than nothing, but still happens after the fact, when the damage is done and the defect distributed to the users. As far as I know, they have no incentive to _wait_ for their patches to be included in upstream. > many [...] maintainers will strongly oppose including distro-specific patches in their packages without a very good reason. Well, fixing security issues is often seen as a "very good reason", completely ignoring that an incomplete and/or errorneous security fix may do more harm than good, and meanwhile provides the users with a false sense of security.
  - feld 10y ago
    This is precisely why I'm against the Linux style "freeze software at version X" methodology.
    - chme 10y ago
      What does the kernel has to do with this? That is an issue some distributions introduced and they have to deal with it or you should choose one that does a rolling release.