6 ms·

> So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything. It creates a security nightm

by rlpb 2y ago

> So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything. It creates a security nightmare. Distributions expect to be able to security patch without waiting for laggard upstreams to bump their pinned dependency versions. If the ecosystem insists that only upstream-sanctioned versions are acceptable, then that runs contrary to this expectation, because it blocks distributions from patching or bumping dependency versions. If this case should be an exception, then you end up with a security team having to patch myriad different versions. That's the security nightmare.

deleted 2y ago
[deleted]
cogman10 2y ago
Fair point. I do think we need to reevaluate how security is managed in terms of software. It's often the case that we say "this library version has a CVE, we need to update it!" However, it's not often the case that the CVE in the library is even exploitable from the parent application. I'm thinking of a recent 9 CVE against zlib... But actually it was a rarely used extension API for working with compressed files. Something like path tracing to see if a vulnerable API is even accessible from the parent application/library before instructing the universe to adopt a new version.
- miki123211 2y ago
  Rust has the advantage of aggressively gating many library APIs behind feature flags as a convention. A lot of third-party libraries consist of a core of the most essential functionality that the entire library just can't go without, and everything else, particularly things that require yet more external dependencies to work, is gated behind a feature. You could imagine a model where security vulnerability reports include a combination of features required to trigger that vulnerability. If the vulnerability was in a rarely-used extension, like it was for Zlib, many dependents would be automatically marked as non-vulnerable because they wouldn't have the necessary feature flag active.
- tsimionescu 2y ago
  I think it's already complicated to find all the software that uses a library version that has a known vulnerability, because of the many slightly different versions floating around, static linking, software running in docker containers etc. Expecting to further identify which applications use a particular part of a library gets even more difficult, and lazy developers will use this as an excuse not to patch far more often than you'll save on unnecessary updates. Not to mention, this already happens to some extent, especially for older versions of software: distributors and developers do sometimes say "we will not provide a patch because even if we use the affected library, we don't use it in a way that triggers the vulnerability".
hamandcheese 2y ago
If the only way a security team can cope is with a single version policy, that sounds to me like a tooling problem. Take Nixpkgs, for example. They have this concept called "default crate overrides" which their rust builder uses, which offers the capability to patch all versions of a crate. That's not to say that Nixpkgs does rust perfectly, but just an example of the sort of tooling a security team should have at their disposal.
- SSLy 2y ago
  The security team got used to c/c++ being the only way to build native binaries, and would prefer to peg other square languages into this round hole. FUD enuses.
- tsimionescu 2y ago
  How does it patch all versions automatically? If the library has been refactored, you still need to modify the patch for the pre-refactor and the post-refractor versions, for example. The closest you might get is a ChatGPT-based tool, but that is nowhere near safe enough for security patches.
  - hamandcheese 2y ago
    I didn't say it's automatic. You can have overrides that target a more narrow range of versions, if you need. If there has been a major refactor, then you need two patches. But it's not rocket science, and you definitely don't need chatgpt. You can also blend both strategies - you might have a version minimization strategy, where you only use, for example, one major version of a library at a time.
aseipp 2y ago
Not all distributions suffer from this, because they have the tooling to patch all crate versions given a name. Compile times are actually the worst part but can be mitigated. But these distros also fundamentally accept the language's compilation model in question, so they have to develop solutions if they want to supply software to their users rather than make up excuses. Most distros don't like vendoring, for reasons. But many code maintainers do like it, for reasons. So it is what it is. There are also more tools than ever to do things like correlate versions of OSS packages with reported vulnerabilities e.g. Google's osv.dev. 95% or more of Rust vendoring isn't actually "vendoring" in the sense you have to figure anything out. The dependencies are literally written in the lock file with the version and that can be traced back to a Git hash automatically in almost all cases. Some crates that bind C libraries might require this work, where you have to look at the code to see "What version of the code did the `cp -R` into here?" but they are practically limited in number, and detectable. You aren't doing any detective work for 98% of this stuff. It can be scaled pretty well with a few (good) heuristics. Rust even has the advantage that large, vast amounts of code is actually statically analyzable under known sets of configurations/features. In the future I suspect a tool like `govulncheck` for Rust will be developed, making accurate vuln tracing even easier. While I'm admittedly biased because I work on a distro where this problem isn't as directly relevant, my answer is that in 2024 if you don't have the tooling to do this stuff, it's absolutely on you. Whether as a policy decision or a technical limitation, whatever.
- tsimionescu 2y ago
  What do you mean that they can patch all crate versions given a name? Sometimes the same patch might be trivially applied to many different versions of a library, but in the general case, this is not true: the amount of work is in direct proportion with the number of library versions you have to patch, even if you know exactly which versions those are. So the difference between maintaining, say, 3 versions of a library, and 30, is going to be ~10× the work, even with tools that instantly identify the exact versions that need to be patched.
- rlpb 2y ago
  Tooling to apply the patches is trivial. This isn't the problem I'm describing. As the sibling comment says, the issue is when the patch doesn't apply cleanly to some subset of versions in use, or even worse if they appear to apply cleanly but leave behind logic bugs. If distributions did approach this by "distro-patching" specific versions, then that would reintroduce the upstream complaint that distros are using versions of dependencies not sanctioned by them. So your approach, even if it did work in the general case, would take you back to square one.

by rlpb 2y ago

deleted 2y ago

[deleted]

cogman10 2y ago

Fair point. I do think we need to reevaluate how security is managed in terms of software. It's often the case that we say "this library version has a CVE, we need to update it!" However, it's not often the case that the CVE in the library is even exploitable from the parent application. I'm thinking of a recent 9 CVE against zlib... But actually it was a rarely used extension API for working with compressed files. Something like path tracing to see if a vulnerable API is even accessible from the parent application/library before instructing the universe to adopt a new version.

miki123211 2y ago
Rust has the advantage of aggressively gating many library APIs behind feature flags as a convention. A lot of third-party libraries consist of a core of the most essential functionality that the entire library just can't go without, and everything else, particularly things that require yet more external dependencies to work, is gated behind a feature. You could imagine a model where security vulnerability reports include a combination of features required to trigger that vulnerability. If the vulnerability was in a rarely-used extension, like it was for Zlib, many dependents would be automatically marked as non-vulnerable because they wouldn't have the necessary feature flag active.
tsimionescu 2y ago
I think it's already complicated to find all the software that uses a library version that has a known vulnerability, because of the many slightly different versions floating around, static linking, software running in docker containers etc. Expecting to further identify which applications use a particular part of a library gets even more difficult, and lazy developers will use this as an excuse not to patch far more often than you'll save on unnecessary updates. Not to mention, this already happens to some extent, especially for older versions of software: distributors and developers do sometimes say "we will not provide a patch because even if we use the affected library, we don't use it in a way that triggers the vulnerability".

hamandcheese 2y ago

If the only way a security team can cope is with a single version policy, that sounds to me like a tooling problem. Take Nixpkgs, for example. They have this concept called "default crate overrides" which their rust builder uses, which offers the capability to patch all versions of a crate. That's not to say that Nixpkgs does rust perfectly, but just an example of the sort of tooling a security team should have at their disposal.

SSLy 2y ago
The security team got used to c/c++ being the only way to build native binaries, and would prefer to peg other square languages into this round hole. FUD enuses.
tsimionescu 2y ago
How does it patch all versions automatically? If the library has been refactored, you still need to modify the patch for the pre-refactor and the post-refractor versions, for example. The closest you might get is a ChatGPT-based tool, but that is nowhere near safe enough for security patches.
- hamandcheese 2y ago
  I didn't say it's automatic. You can have overrides that target a more narrow range of versions, if you need. If there has been a major refactor, then you need two patches. But it's not rocket science, and you definitely don't need chatgpt. You can also blend both strategies - you might have a version minimization strategy, where you only use, for example, one major version of a library at a time.

aseipp 2y ago

Not all distributions suffer from this, because they have the tooling to patch all crate versions given a name. Compile times are actually the worst part but can be mitigated. But these distros also fundamentally accept the language's compilation model in question, so they have to develop solutions if they want to supply software to their users rather than make up excuses. Most distros don't like vendoring, for reasons. But many code maintainers do like it, for reasons. So it is what it is. There are also more tools than ever to do things like correlate versions of OSS packages with reported vulnerabilities e.g. Google's osv.dev. 95% or more of Rust vendoring isn't actually "vendoring" in the sense you have to figure anything out. The dependencies are literally written in the lock file with the version and that can be traced back to a Git hash automatically in almost all cases. Some crates that bind C libraries might require this work, where you have to look at the code to see "What version of the code did the `cp -R` into here?" but they are practically limited in number, and detectable. You aren't doing any detective work for 98% of this stuff. It can be scaled pretty well with a few (good) heuristics. Rust even has the advantage that large, vast amounts of code is actually statically analyzable under known sets of configurations/features. In the future I suspect a tool like `govulncheck` for Rust will be developed, making accurate vuln tracing even easier. While I'm admittedly biased because I work on a distro where this problem isn't as directly relevant, my answer is that in 2024 if you don't have the tooling to do this stuff, it's absolutely on you. Whether as a policy decision or a technical limitation, whatever.

tsimionescu 2y ago
What do you mean that they can patch all crate versions given a name? Sometimes the same patch might be trivially applied to many different versions of a library, but in the general case, this is not true: the amount of work is in direct proportion with the number of library versions you have to patch, even if you know exactly which versions those are. So the difference between maintaining, say, 3 versions of a library, and 30, is going to be ~10× the work, even with tools that instantly identify the exact versions that need to be patched.
rlpb 2y ago
Tooling to apply the patches is trivial. This isn't the problem I'm describing. As the sibling comment says, the issue is when the patch doesn't apply cleanly to some subset of versions in use, or even worse if they appear to apply cleanly but leave behind logic bugs. If distributions did approach this by "distro-patching" specific versions, then that would reintroduce the upstream complaint that distros are using versions of dependencies not sanctioned by them. So your approach, even if it did work in the general case, would take you back to square one.