5 ms·

There may be further reasons they don't want to ship crypto libraries as part of the Rust language distribution when it's not yet even properly out the door. Th

There may be further reasons they don't want to ship crypto libraries as part of the Rust language distribution when it's not yet even properly out the door. That doesn't stop third parties from writing crypto libraries in Rust and then distributing them separately from the core platform. I can think of a couple obvious reasons why they would take this approach: (1) Crypto is hard, and they want to get the core platform out the door in a usable form on a relatively tight schedule. (2) Designating an official Rust crypto solution would be a social statement about what crypto code you're supposed to use in Rust, even if the quality of the code itself is inferior due to being newly written and unvetted. This is riskier than just using existing C libraries, because at least now they can't be blamed for any horrible security bugs in libraries they didn't write. If you'd only read past the specific sentence you quoted, you'd see that they do have plans to build crypto solutions in Rust, but that they're taking an extremely conservative approach to making it happen, and developing it "out of tree," ie. not as part of the Rust language codebase. Moving conservatively with respect to crypto development is not inappropriate. I'm sure you understand the sensitive nature of crypto libraries and why they need to be treated with as much care as possible.

leorocky 12y ago
I totally agree with everything you've said and I did read the entire paragraph, but speaking as an application developer as long as crypto is an issue in Rust, because there aren't libraries and they haven't yet implemented crypto, Rust is not a good option. I'm not trying to write a middlebrow dismissal, I'm simply explaining honestly why I don't use Rust and why I will not use Rust for the foreseeable future. The implication being that it's not just about me, but any application developer would pass on Rust as long as the only crypto options are to import c libraries. I could be mistaken in this.
- iopq 12y ago
  If you can link against crypto libraries written in C, why is that an issue? If Rust 1.0 comes out with the SMALLEST amount of features possible that's not a problem, since you can always add more features in a backwards-compatible manner. You can't take away a badly-designed stdlib. Now people already use your poorly-designed APIs. You have to support them for 50 years.
  - Touche 12y ago
    > If you can link against crypto libraries written in C, why is that an issue? Rust is memory safe and C is not, so it seems to go against the benefits of Rust.
    - pcwalton 12y ago
      It's a pragmatic decision. Incorrectly implemented crypto has worse consequences than potential memory safety problems. We have crypto experts on staff who could write this kind of thing, but we have a shipping schedule to meet and crypto is the kind of thing we definitely don't want to rush out the door.
      - Touche 12y ago
        Doing either (incorrectly implementing crypto or telling users to use an unsafe C library) would be highly irresponsible. I respect the hell out of you and your team but I think you are dead wrong on this one. Have your domain experts take their time and do it right.
        acqq 12y ago
        I agree, especially interesting because in a good written crypto some functions should spend always the same time, independent of the input, and you have to know if you designed your language good enough to even make such crypto possible.
        pcwalton 12y ago
        This shouldn't be a problem. If you can do constant-time operations in C, you can do them in Rust, by dint of the fact that you can more or less generate any LLVM IR you'd like in Rust, up to and including inline asm.
        nightpool 12y ago
        There are plenty of safe C crypto libraries. NSS, OpenSSL, and gnuTLS are all widely used by a LOT of sites, and, recent OpenSSL vulnerability aside, have a great track record. What would you suggest using?
- bryanlarsen 12y ago
  That's just another way of saying that Rust is not ready for wide use. Nobody disagrees with that. The OP is basically saying that "we need these 7 things to be ready for prime time".
  - pcwalton 12y ago
    I don't think we need all of those seven things to be ready for use, otherwise we'd block 1.0 on them. They're all high-priority though.

leorocky 12y ago

I totally agree with everything you've said and I did read the entire paragraph, but speaking as an application developer as long as crypto is an issue in Rust, because there aren't libraries and they haven't yet implemented crypto, Rust is not a good option. I'm not trying to write a middlebrow dismissal, I'm simply explaining honestly why I don't use Rust and why I will not use Rust for the foreseeable future. The implication being that it's not just about me, but any application developer would pass on Rust as long as the only crypto options are to import c libraries. I could be mistaken in this.

iopq 12y ago
If you can link against crypto libraries written in C, why is that an issue? If Rust 1.0 comes out with the SMALLEST amount of features possible that's not a problem, since you can always add more features in a backwards-compatible manner. You can't take away a badly-designed stdlib. Now people already use your poorly-designed APIs. You have to support them for 50 years.
- Touche 12y ago
  > If you can link against crypto libraries written in C, why is that an issue? Rust is memory safe and C is not, so it seems to go against the benefits of Rust.
  - pcwalton 12y ago
    It's a pragmatic decision. Incorrectly implemented crypto has worse consequences than potential memory safety problems. We have crypto experts on staff who could write this kind of thing, but we have a shipping schedule to meet and crypto is the kind of thing we definitely don't want to rush out the door.
    - Touche 12y ago
      Doing either (incorrectly implementing crypto or telling users to use an unsafe C library) would be highly irresponsible. I respect the hell out of you and your team but I think you are dead wrong on this one. Have your domain experts take their time and do it right.
      - acqq 12y ago
        I agree, especially interesting because in a good written crypto some functions should spend always the same time, independent of the input, and you have to know if you designed your language good enough to even make such crypto possible.
        pcwalton 12y ago
        This shouldn't be a problem. If you can do constant-time operations in C, you can do them in Rust, by dint of the fact that you can more or less generate any LLVM IR you'd like in Rust, up to and including inline asm.
      - nightpool 12y ago
        There are plenty of safe C crypto libraries. NSS, OpenSSL, and gnuTLS are all widely used by a LOT of sites, and, recent OpenSSL vulnerability aside, have a great track record. What would you suggest using?
bryanlarsen 12y ago
That's just another way of saying that Rust is not ready for wide use. Nobody disagrees with that. The OP is basically saying that "we need these 7 things to be ready for prime time".
- pcwalton 12y ago
  I don't think we need all of those seven things to be ready for use, otherwise we'd block 1.0 on them. They're all high-priority though.