To me, ring’s stance on portability and such seems a little silly - relying so much on platform-specific C and assembly, when they could just have a Rust implementation that’d work on almost any platform. You could then derive and test riced out assembly implementations against that. The way they do things now leads to a ton of friction for platforms off the beaten path as soon as they need anything relating to cryptography.
I concur. I was building my Rust module for a Flutter application running on Android. With Ring there were a lot of compilation issues, so I gave up. Luckily, native-tls-vendored feature in reqwest crate just made things to work.
I know that I was probably missing some libraries to do cross compilation but I just don’t want all that extra work. I use Rust specifically to have a lot less headaches. Sadly, it is not always the case.
Yep. This exact problem made me disqualify ring when hacking on bitbottle, and it caused me a lot of early headaches trying to find native implementations (not always successful). Given how perfectly-suited rust is for doing crypto work, I hope this improves over time.
With how the author of ring handled yanking and reacting to external requests, I get a feeling that we will see some kind of breakage in the future. I wouldn’t even be surprised if they would like to get paid for adding another target to their repo, which they also would have to maintain. But I don’t think that will generate much sympathy. A lot of people would probably rather turn the ecosystem into using native-tls, than dealing with this.
Bunnie has basically a mirror of this post.