3 ms·

I doubt that everyone is being as deligent as you. I suspect leaving security updates to upstream is not a recipe for secure distributions. For the record, I

by rwj 6y ago

I doubt that everyone is being as deligent as you. I suspect leaving security updates to upstream is not a recipe for secure distributions. For the record, I see both sides as having legitimate concerns.

PurpleFoxy 6y ago
It largely doesn’t matter because the future is sandboxed flatpak apps. So even if your notes app has an old dependency, it doesn’t matter because it has access to nothing but your notes.
MaulingMonkey 6y ago
> I doubt that everyone is being as deligent as you. Agreed. > I suspect leaving security updates to upstream is not a recipe for secure distributions. Agreed - but neither is leaving it to a balkanized downstream. Debian's getting picked on in another thread: https://news.ycombinator.com/item?id=26207965 https://news.ycombinator.com/item?id=26207965 . The recipe for secure software is people doing the work, force-multiplied by cooperation and tooling. Safe languages, sane APIs, tests, CI, code reviews, audits, static analysis, dependency tooling, ease of forking when upstream is abandoned or unresponsible, easy build setups, good cross-platform support... the list goes on. To hack on the average abandoned Rust codebase, "git clone ..." + "cargo build" alone probably just works, and I can start making, testing, and upstreaming incremental improvements one out-of-date or similarly abandoned dependency, bugfix, or feature branch at a time. To hack on the average abandoned C codebase, I probably need new build rules and an undocumented list of extra build tools unique to this project (many of which almost certainly lack official windows binaries), and I'm probably left with a completely broken build that I can't even test my new build rules against - due to the unpinned versions causing multiple dependencies to be several major versions full of breaking changes out of sync with what the code expected. If I can be bothered to fix the build, the resulting megacommit will make any reviewer's eyes glaze over. You can guess which of the two I'll bother trying to patch.
- laykg 6y ago
  The "balkanized" downstream has been working quite well, unlike malicious packages on PyPI. The only major issue was the OpenSSL fiasco that was due to overpatching upstream. Overpatching indeed should stop but is not a flaw of the package manager itself.
  - MaulingMonkey 6y ago
    > The "balkanized" downstream has been working quite well Disagreed. > The only major issue was the OpenSSL fiasco that was due to overpatching upstream There's a reason OpenSSL got forked as LibreSSL/BoringSSL - even downstream realized their approach wasn't cutting it, and they needed to go upstream and start burning everything down with fire. Granted, OpenSSL has been getting their act together - so perhaps unforking might be warranted? Meanwhile, the CVE database continues to be flooded with memory vulnerabilities. Distros dutifully push out the patches when they get them, but that's the bare minimum.

by rwj 6y ago

PurpleFoxy 6y ago

It largely doesn’t matter because the future is sandboxed flatpak apps. So even if your notes app has an old dependency, it doesn’t matter because it has access to nothing but your notes.

MaulingMonkey 6y ago

> I doubt that everyone is being as deligent as you. Agreed. > I suspect leaving security updates to upstream is not a recipe for secure distributions. Agreed - but neither is leaving it to a balkanized downstream. Debian's getting picked on in another thread: https://news.ycombinator.com/item?id=26207965 https://news.ycombinator.com/item?id=26207965 . The recipe for secure software is people doing the work, force-multiplied by cooperation and tooling. Safe languages, sane APIs, tests, CI, code reviews, audits, static analysis, dependency tooling, ease of forking when upstream is abandoned or unresponsible, easy build setups, good cross-platform support... the list goes on. To hack on the average abandoned Rust codebase, "git clone ..." + "cargo build" alone probably just works, and I can start making, testing, and upstreaming incremental improvements one out-of-date or similarly abandoned dependency, bugfix, or feature branch at a time. To hack on the average abandoned C codebase, I probably need new build rules and an undocumented list of extra build tools unique to this project (many of which almost certainly lack official windows binaries), and I'm probably left with a completely broken build that I can't even test my new build rules against - due to the unpinned versions causing multiple dependencies to be several major versions full of breaking changes out of sync with what the code expected. If I can be bothered to fix the build, the resulting megacommit will make any reviewer's eyes glaze over. You can guess which of the two I'll bother trying to patch.

laykg 6y ago
The "balkanized" downstream has been working quite well, unlike malicious packages on PyPI. The only major issue was the OpenSSL fiasco that was due to overpatching upstream. Overpatching indeed should stop but is not a flaw of the package manager itself.
- MaulingMonkey 6y ago
  > The "balkanized" downstream has been working quite well Disagreed. > The only major issue was the OpenSSL fiasco that was due to overpatching upstream There's a reason OpenSSL got forked as LibreSSL/BoringSSL - even downstream realized their approach wasn't cutting it, and they needed to go upstream and start burning everything down with fire. Granted, OpenSSL has been getting their act together - so perhaps unforking might be warranted? Meanwhile, the CVE database continues to be flooded with memory vulnerabilities. Distros dutifully push out the patches when they get them, but that's the bare minimum.