4 ms·

> 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream Having had quite a lot of experience of both, what I call, maintained

by ris 9y ago

> 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream Having had quite a lot of experience of both, what I call, maintained packages and wild west packages (e.g. pypi), I would trust the former over the latter any day of the week. Developers generally do not make tremendously good maintainers. They tend to to only really care about the latest versions of anything, don't take particular care to make sure their package works well with other packages, rarely backport security fixes, and frequently do everything in a unilateral way. (I've seen it all, subtly different tarballs uploaded under the same version number, old releases deleted, breaking changes released under minor version bumps, addition of user-hostile "features", downloading & installing unexpected random binaries from the internet in attempt to make everything "just work", and of course they're forever bundling odd versions of other packages which they then don't maintain...) Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). These days I tend to use a debian base system with Nix on top of it for when I need specific, repeatable or more recent versions of something.

jancsika 9y ago
> Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). Is there a policy that requires Debian package maintainers to seek mentorship of upstream when patching core packages? I understand your point about maintained packages. But it's only a significant advantage if the maintainer's decisions must be filtered through the lens of the software maintainers. Otherwise one must trade the narrow expertise of the software maintainer for the wider expertise of the package maintainer. That doesn't seem like a wise tradeoff IMO, and I don't see how a future openssl debacle could be prevented otherwise.
willtim 9y ago
Having package maintainers touch any code, even to backport security fixes, is far from ideal. In 2006, a big security flaw was introduced into Debian's OpenSSL by the maintainer, because he changed code that he did not fully understand. The flaw wasn't discovered until 2008: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
- ris 9y ago
  ...as I indeed mentioned. But we've got to remember that attitudes to security and understanding of subtleties around crypto code were very different a decade ago, the output from automated checking tools was trusted significantly more, and we're talking about OpenSSL, a project whose source is generally acknowledged to be full of Weird And Inadvisable Shit anyway. The example you're leaning on was basically a perfect storm that resulted in the worst possible scenario. On the other hand, package maintainers fix security issues on versions of packages the developers have stopped caring about every day of the week, and of course these never hit the headlines. And of course I'd never suggest that any package maintainer could ever know better than you. Though unfortunately such superior and unilateral attitudes are one of the things that maintainers are needed to protect against.
  - ris 9y ago
    ^ I didn't mean the parent comment to sound so personal at the end. Apologies.

by ris 9y ago

jancsika 9y ago

> Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). Is there a policy that requires Debian package maintainers to seek mentorship of upstream when patching core packages? I understand your point about maintained packages. But it's only a significant advantage if the maintainer's decisions must be filtered through the lens of the software maintainers. Otherwise one must trade the narrow expertise of the software maintainer for the wider expertise of the package maintainer. That doesn't seem like a wise tradeoff IMO, and I don't see how a future openssl debacle could be prevented otherwise.

willtim 9y ago

Having package maintainers touch any code, even to backport security fixes, is far from ideal. In 2006, a big security flaw was introduced into Debian's OpenSSL by the maintainer, because he changed code that he did not fully understand. The flaw wasn't discovered until 2008: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...

ris 9y ago
...as I indeed mentioned. But we've got to remember that attitudes to security and understanding of subtleties around crypto code were very different a decade ago, the output from automated checking tools was trusted significantly more, and we're talking about OpenSSL, a project whose source is generally acknowledged to be full of Weird And Inadvisable Shit anyway. The example you're leaning on was basically a perfect storm that resulted in the worst possible scenario. On the other hand, package maintainers fix security issues on versions of packages the developers have stopped caring about every day of the week, and of course these never hit the headlines. And of course I'd never suggest that any package maintainer could ever know better than you. Though unfortunately such superior and unilateral attitudes are one of the things that maintainers are needed to protect against.
- ris 9y ago
  ^ I didn't mean the parent comment to sound so personal at the end. Apologies.