5 ms·

Also, ring enforces everyone to use the latest version by pruning older versions from crates.io, which means your builds will fail every time they update. Main

Also, ring enforces everyone to use the latest version by pruning older versions from crates.io, which means your builds will fail every time they update. Main reason I stopped using it.

dochtman 5y ago
That issue should be fixed in the next release. It is definitely a nuisance, but fixing it is not easy due to the assembly code involved.
tialaramex 5y ago
Of course, if our claim is that we want to avoid security bugs, and we accept the principle that (without some more specific definition) all bugs are security bugs, then any time ring fixes a bug we want to avoid using the old version... Now for all I know, ring has never fixed any bugs and it just loves adding new API features so that this pruning has no desirable security properties at all, but in principle I can see that this is the equivalent of the standard boilerplate Linux release text which tells you that you should update to the latest kernel because they fixed bugs. If you have a complete threat model and if you are capable of the insight needed to examine all changes and determine how they impact that model, you could successfully choose whether to upgrade based on whether a new version fixes a bug you care about. But chances are you don't have such a model and even if you did you aren't capable of the inhuman levels of insight needed, even in a language like Rust (and forgetting that we're talking about this because large parts of ring aren't even in Rust).
- volta83 5y ago
  crates.io and the Rust community adheres to semantic versioning. If ring wants to notify me that I should update, they should send an email to a security mailing list, open a CVE, register the cve in any of the rust services to notify users with those dependencies (there are some, like crev), etc. Pruning your releases from crates.io just means that I am going to be annoyed the first time it happens, will start looking for a solution the second time it happens, and it won't happen a third time (and it didn't). If you want to wake me up a Saturday at 4 am, the world better be on fire. This is probably the only dependency I can remember as being... more than annoying, toxic. I still prevent any of my dependencies from ending up with ring as a dependency. If that shows up in our dependency tree, CI fails, and that change cannot be committed. Unfortunately, this pruning of old releases was only one of the issues with ring (there were others, like cross-compiling it wasn't easy, etc.). All in all it was a no brainer to drop it as a dependency. I don't think I've ever met a rust dev with something nice to say about `ring`. In a meetup a couple of years ago another rustacean said: "`ring` is so secure that it protects you from using it in your projects". Sums it pretty well. The library has couple of thousands of daily downloads so for the latest version, and like 25k daily downloads for other versions, so maybe things changed now.
  - briansmith 5y ago
    When I merged security fixes from BoringSSL/OpenSSL, I yanked the old versions of ring that didn't have the security fixes. I thought that was a pretty reasonable policy, however people who like to comment in these forums disagreed very loudly, so I stopped doing that. Not sure that's better, but there's less complaining. In general, my initial thinking was based too much on the assumption that people would help maintain the things that depend on ring to update them to the latest release. It turns out there's less cooperative maintenance like that than I expected.
    - jzoch 5y ago
      I loved your policy and appreciated how principled it was. People here are too harsh and most of them don't write code in Rust where regular updates are much more the norm than other communities.
      - richardwhiuk 5y ago
        Yanking releases which have bugs / vulnerabilities in them is very much not the norm in the Rust community. This is why projects like https://github.com/RustSec https://github.com/RustSec exist.
        steveklabnik 5y ago
        I don't know about that, crates that RustSec has advisories for are often yanked, in my experience. Bugs? No. Security bugs? Yes.
        richardwhiuk 5y ago
        Hyper 0.11.26 - https://crates.io/crates/hyper/0.11.26 https://crates.io/crates/hyper/0.11.26 Not yanked. Vulnerable to https://github.com/RustSec/advisory-db/blob/main/crates/hyper/RUSTSEC-2020-0008.md https://github.com/RustSec/advisory-db/blob/main/crates/hype...
briansmith 5y ago
That hasn't been the case for a long time, a year or more.
CodesInChaos 5y ago
I thought crates.io doesn't allow removal? You can yank crate versions, but that doesn't affect builds which lock a version via cargo.lock so failing builds shouldn't be an issue.
- steveklabnik 5y ago
  They meant yanking.
Arnavion 5y ago
Your builds will only fail if you don't check in your lockfile.

Also, ring enforces everyone to use the latest version by pruning older versions from crates.io, which means your builds will fail every time they update. Main reason I stopped using it.

dochtman 5y ago

That issue should be fixed in the next release. It is definitely a nuisance, but fixing it is not easy due to the assembly code involved.

tialaramex 5y ago

Of course, if our claim is that we want to avoid security bugs, and we accept the principle that (without some more specific definition) all bugs are security bugs, then any time ring fixes a bug we want to avoid using the old version... Now for all I know, ring has never fixed any bugs and it just loves adding new API features so that this pruning has no desirable security properties at all, but in principle I can see that this is the equivalent of the standard boilerplate Linux release text which tells you that you should update to the latest kernel because they fixed bugs. If you have a complete threat model and if you are capable of the insight needed to examine all changes and determine how they impact that model, you could successfully choose whether to upgrade based on whether a new version fixes a bug you care about. But chances are you don't have such a model and even if you did you aren't capable of the inhuman levels of insight needed, even in a language like Rust (and forgetting that we're talking about this because large parts of ring aren't even in Rust).

volta83 5y ago
crates.io and the Rust community adheres to semantic versioning. If ring wants to notify me that I should update, they should send an email to a security mailing list, open a CVE, register the cve in any of the rust services to notify users with those dependencies (there are some, like crev), etc. Pruning your releases from crates.io just means that I am going to be annoyed the first time it happens, will start looking for a solution the second time it happens, and it won't happen a third time (and it didn't). If you want to wake me up a Saturday at 4 am, the world better be on fire. This is probably the only dependency I can remember as being... more than annoying, toxic. I still prevent any of my dependencies from ending up with ring as a dependency. If that shows up in our dependency tree, CI fails, and that change cannot be committed. Unfortunately, this pruning of old releases was only one of the issues with ring (there were others, like cross-compiling it wasn't easy, etc.). All in all it was a no brainer to drop it as a dependency. I don't think I've ever met a rust dev with something nice to say about `ring`. In a meetup a couple of years ago another rustacean said: "`ring` is so secure that it protects you from using it in your projects". Sums it pretty well. The library has couple of thousands of daily downloads so for the latest version, and like 25k daily downloads for other versions, so maybe things changed now.
- briansmith 5y ago
  When I merged security fixes from BoringSSL/OpenSSL, I yanked the old versions of ring that didn't have the security fixes. I thought that was a pretty reasonable policy, however people who like to comment in these forums disagreed very loudly, so I stopped doing that. Not sure that's better, but there's less complaining. In general, my initial thinking was based too much on the assumption that people would help maintain the things that depend on ring to update them to the latest release. It turns out there's less cooperative maintenance like that than I expected.
  - jzoch 5y ago
    I loved your policy and appreciated how principled it was. People here are too harsh and most of them don't write code in Rust where regular updates are much more the norm than other communities.
    - richardwhiuk 5y ago
      Yanking releases which have bugs / vulnerabilities in them is very much not the norm in the Rust community. This is why projects like https://github.com/RustSec https://github.com/RustSec exist.
      - steveklabnik 5y ago
        I don't know about that, crates that RustSec has advisories for are often yanked, in my experience. Bugs? No. Security bugs? Yes.
        richardwhiuk 5y ago
        Hyper 0.11.26 - https://crates.io/crates/hyper/0.11.26 https://crates.io/crates/hyper/0.11.26 Not yanked. Vulnerable to https://github.com/RustSec/advisory-db/blob/main/crates/hyper/RUSTSEC-2020-0008.md https://github.com/RustSec/advisory-db/blob/main/crates/hype...

briansmith 5y ago

That hasn't been the case for a long time, a year or more.

CodesInChaos 5y ago

I thought crates.io doesn't allow removal? You can yank crate versions, but that doesn't affect builds which lock a version via cargo.lock so failing builds shouldn't be an issue.

steveklabnik 5y ago
They meant yanking.

Arnavion 5y ago

Your builds will only fail if you don't check in your lockfile.