5 ms·
This issue highlights another common problem on FOSS: If I create a small utility "just for fun" and someone includes it in a major distro and then nobody (inc
by pawadu 10y ago
This issue highlights another common problem on FOSS:
If I create a small utility "just for fun" and someone includes it in a major distro and then nobody (including myself) touches it for 10 years, who is to blame if there are security (or any other) issues with the software?
- benchaney 10y agoWhoever included it in a major distro is to blame.
- pawadu 10y agoYes, but is there any kind of vetting process in any of the major distros? Does any distro (outside OpenBSD) have a continuous process of re-evaluating included packages?
- madez 10y agoSince quite some time I'm more than annoyed by the unnecessary complexity and difficulty of traditional distributions caused by inconsistent system tools and backwards compatibility with antique things that block modernization and simplification. Do you know whether OpenBSD strives for consistency and throws away stuff when there is a better alternative?
- jlgaddis 10y agoThey replaced OpenSSL with their own LibreSSL and sudo with doas, among others.
- gkya 10y agoThe whole BSD family of operating systems provide far better consistency than the Linux distro universe, as they are the ones to directly maintain the base system's codebase (POSIX utilites, OS-specific utilites, the kernel, the drivers, init system). Linux distros, on the other hand, are just a juxtaposition of software from a plethora of sources.
- jlgaddis 10y agoOpenBSD does not "evaluate" packages (only the base system).
- bonzini 10y agoIt's a new regression, only found in Debian stretch (not yet released) and caused by an incompatible change in another package. As far as Debian is concerned, this is just the process working as intended.
- jonathanstrange 10y agoUnless programmers are treated by the law in a similar way as engineers (and there are reasons for an against that), blaming someone is not a very valuable activity. A better question is who will fix it and/or whether the maintainer should remove the package. I think such a package should be removed ASAP unless someone fixes the problem within a short amount of time.
- pawadu 10y agoI think you are missing my point. What I am saying is "how could this be included in Debian in the first place?"
- throwaway7767 10y agoIt wasn't, did you read the article? No stable release ever included this. It was caught while in the testing repository, which is for, you know, testing stuff and finding issues.
- daenney 10y agoWhy do we need to blame anyone? Software has a lifecycle too, what was well maintained 10 year ago isn't necessarily maintained anymore because people have moved on. Ten year ago adding this to Debian in its current state might have been the right thing to do. Now, as other components have evolved, it's introduced a problem. If you are going to not include software because ten years down the line it might have a bug and you want to have someone to blame for it you're going to end up with a very empty package repository. Once the bug is found a ticket gets filed for it, the security teams handle it and life moves on. If the software instead isn't deemed necessary a recommendation is made to remove it from the distribution instead.
- pawadu 10y agoBecause we need some kind of quality assurance or else we are left with cowboy developers moving fast and breaking things on other peoples machines.
- daenney 10y agoQuality assurance doesn't have to have anything to do with blaming people.
- slededit 10y agoChange the question to "who owned maintenance of the code" and it becomes valid. The kernel of the question is in fact interesting. Distros have far too much software for any reasonable person to assume they maintain all of it.
- lmm 10y agoThe whole point of the major distributions - particularly those with a release cycle - is that they do integration testing. I think two Debian policies interact poorly: heavily modifying upstream sofware, and not doing their own security review. To my mind the Debian SSH key vulnerability was a predictable result of this policy combination (which Debian did not see fit to change AIUI) and similar issues are to be expected from Debian going forward.