5 ms·

Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. T

Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. The result is incredibly poor. I deploy to consoles. I deploy to mobile. I deploy to the web via WASM. I deploy to windows as EXEs, MSIs, and APPXes. Your distro's linux package manager won't help me keep my dependencies up to date in any of these places. They won't even help me keep my dependencies up to date on linux, when the packages lag behind upstream - or in disconnected applications with no web access to update the linux distro with. How do I get security updates onto my OpenDingux RG350M? Through new images and newly built and pushed OPKs, not through fetched APT packages. With versions pinned upstream at the app source code level, I can actually see what versions I've shipped had a vulnerable version, and push updates / advise my users appropriately. Stale dependencies are admittedly a concern, but they're not a concern that's even remotely fixed by having an unpinned, floating version. There's a reason software started bundling auto-updaters, and it's not because linux distros were handling everything perfectly fine already. The article defends, among others, the Rust approach. Apps are pinned to exact versions via lockfiles. Libs are pinned to approximate verisons by semver, with CI typically catching when that breaks. This is a nice balance, and applies social pressure that encourages Rust projects to properly adhere to semver. Dependabot can flag dependencies with security issues, dependencies without security issues that are just old, auto-PR version updates to see if they pass CI or need manual action, and even auto-merge changes if you let it when the builds go green. I've used this article as an excuse to double check my settings. I didn't have dependabot enabled for a couple of private repositories. I have a few flagged issues in an offline, user-inputless, electron clock widget I keep on my windows desktop. Harmless... but if they hadn't been? This would let me know I need to rebuild, retest, and redeploy. Via push notifcation. Despite the bundling approximating static linking. Despite the lack of linux. Despite the complete lack of an OS package manager, or even proper CI scripts. It's a much more versatile and portable approach.

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
PoignardAzur 6y ago
> Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. The result is incredibly poor. I think that points needs to be made more often. People focus a lot on active decisions that have the potential to introduce security vulnerabilities, but they underestimate how similar problems may exist in the status quo. Having a single, only-one-canonical version dependency system is a recipe for package managers that update slowly because any dependency change may break an unrelated package. Frankly, being able to say "just install every dependency and be done with it" and have Cargo/npm/etc handle all the conflicts implicitly is a huge time-saver. I think people underestimate how valuable that saved time is, both in terms of adding features and maintaining security.

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

PoignardAzur 6y ago

> Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. The result is incredibly poor. I think that points needs to be made more often. People focus a lot on active decisions that have the potential to introduce security vulnerabilities, but they underestimate how similar problems may exist in the status quo. Having a single, only-one-canonical version dependency system is a recipe for package managers that update slowly because any dependency change may break an unrelated package. Frankly, being able to say "just install every dependency and be done with it" and have Cargo/npm/etc handle all the conflicts implicitly is a huge time-saver. I think people underestimate how valuable that saved time is, both in terms of adding features and maintaining security.