7 ms·

It seems like the RustSec "unmaintained" notice worked as intended. Unmaintained dependencies represent a latent security risk as they will almost certainly not

It seems like the RustSec "unmaintained" notice worked as intended. Unmaintained dependencies represent a latent security risk as they will almost certainly not respond to any future vulnerability; identifying this risk before an incident happens is much better than trying to figure out response in the moment during an incident. Armin's answer here, of taking on explicit ownership and responsibility for the third-party code they use, seems like a reasonable and socially desirable response. Yeah, I get that it's annoying, but this is (IMO) pretty much how open source is supposed to work.

burntsushi 3y ago
A latent risk for sure, but this is being handled like an urgent risk because everybody's CI is lighting up. But it's not an urgent risk. So I do not think the system is working as it is intended, although it's hard for me to know exactly what the full intent here. (Since the resulting behavior is likely a confluence of several different systems, so I'm not sure there is one single coherent "intent" per se.)
- alilleybrinker 3y ago
  Yeah, I'd put the blame for that on the tools / systems which consume and report this kind of vulnerability data. They (at least as far as I've seen) don't really differentiate between severities of vulnerabilities. On the one hand, a strong preference toward "just patch" for vulnerabilities can make a lot of sense (the more that mechanism is flexed, the better it moves when you really need it, and rapid integration of fixes reduces time for exploitation by attackers), but here it's applied to a maintenance notice that ought to be treated a little differently. Nonetheless, I think RustSec's feed is working as intended, and I'd put the expectation on the consuming tools (including `cargo-audit`, which I believe is largely maintained by the same people that maintain the RustSec vulnerability database) to change.
keybored 3y ago
> Armin's answer here, of taking on explicit ownership and responsibility for the third-party code they use, seems like a reasonable and socially desirable response. It seems like he vendored it in order to avoid the useless alarm bells going off. Don’t we have a `Cargo.lock`? Just keeping the status quo seems fine. But other people didn’t like it because of these automated alarm bells, hence it becomes “socially desirable” to do something that doesn’t materially make a difference.
- alilleybrinker 3y ago
  Bob Nystrom (munificent) addressed in elsewhere in this thread, and I’ll repeat his point here: vendoring does make a meaningful difference, because he’s taking responsibility for the code. Separately, I do hope VEX becomes more real / takes off to help address issues of non-applicability for vulnerabilities. That said, I don’t think this is a non-applicability scenario.
  - keybored 3y ago
    Other than an American with a Scandinavian name calling it responsible, what technical difference does it make compared to letting it sit around as a locked dependency? Maybe it makes a technical difference in Rust, I’m not sure. I’m not sold on the argument in the other comment. It’s just a may. Something is not worth more just because there is a potential for something.
    - sunshowers 3y ago
      One difference is that a lockfile doesn't apply transitively, while vendoring does.
  - remram 3y ago
    > he’s taking responsibility for the code Is he fixing the bugs reported against the defunct upstream? If not, what is the improvement? And if yes, how can will the rest of the library users benefit from those fixes?
  - tempaccount420 3y ago
    > he's taking responsibility for the code Here's a quote from the project's license: > 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

burntsushi 3y ago

A latent risk for sure, but this is being handled like an urgent risk because everybody's CI is lighting up. But it's not an urgent risk. So I do not think the system is working as it is intended, although it's hard for me to know exactly what the full intent here. (Since the resulting behavior is likely a confluence of several different systems, so I'm not sure there is one single coherent "intent" per se.)

alilleybrinker 3y ago
Yeah, I'd put the blame for that on the tools / systems which consume and report this kind of vulnerability data. They (at least as far as I've seen) don't really differentiate between severities of vulnerabilities. On the one hand, a strong preference toward "just patch" for vulnerabilities can make a lot of sense (the more that mechanism is flexed, the better it moves when you really need it, and rapid integration of fixes reduces time for exploitation by attackers), but here it's applied to a maintenance notice that ought to be treated a little differently. Nonetheless, I think RustSec's feed is working as intended, and I'd put the expectation on the consuming tools (including `cargo-audit`, which I believe is largely maintained by the same people that maintain the RustSec vulnerability database) to change.

keybored 3y ago

> Armin's answer here, of taking on explicit ownership and responsibility for the third-party code they use, seems like a reasonable and socially desirable response. It seems like he vendored it in order to avoid the useless alarm bells going off. Don’t we have a `Cargo.lock`? Just keeping the status quo seems fine. But other people didn’t like it because of these automated alarm bells, hence it becomes “socially desirable” to do something that doesn’t materially make a difference.

alilleybrinker 3y ago
Bob Nystrom (munificent) addressed in elsewhere in this thread, and I’ll repeat his point here: vendoring does make a meaningful difference, because he’s taking responsibility for the code. Separately, I do hope VEX becomes more real / takes off to help address issues of non-applicability for vulnerabilities. That said, I don’t think this is a non-applicability scenario.
- keybored 3y ago
  Other than an American with a Scandinavian name calling it responsible, what technical difference does it make compared to letting it sit around as a locked dependency? Maybe it makes a technical difference in Rust, I’m not sure. I’m not sold on the argument in the other comment. It’s just a may. Something is not worth more just because there is a potential for something.
  - sunshowers 3y ago
    One difference is that a lockfile doesn't apply transitively, while vendoring does.
- remram 3y ago
  > he’s taking responsibility for the code Is he fixing the bugs reported against the defunct upstream? If not, what is the improvement? And if yes, how can will the rest of the library users benefit from those fixes?
- tempaccount420 3y ago
  > he's taking responsibility for the code Here's a quote from the project's license: > 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.