Rustls Can Now Work With Nginx Via New OpenSSL Compatibility Layer

[Daktyl198]

Reading about Dependabot in their documentation, their use case seems not to auto upgrade just to get newer versions but to patch known security vulnerabilities:

That sounds like the opposite of insecurely updating dependencies, of course as long as the developers trust Dependabot.

That's one way of using it. I usually just see it being used to upgrade to the latest version of dependencies, not just security updates. Maybe I just browse more GitHub repos than the average person and so see more awful usage of tools.

[jacob]

I would agree with you, except that most developers (not saying the rustls guys) just auto-update their dependencies via bots. The bot creates a PR that runs through checks to make sure nothing breaks, and if all tests pass the bot either pushes the commit, or a dev will come in and push it without ever looking at the changes made to the dependency. In a perfect world, everything you say makes sense. In the real world, people are lazy and dumb. That includes developers.

Honestly I don't know of any Rust project that uses a bot to continuously update its dependencies. Not saying it doesn't exist, it just doesn't happen to be a common practice like it might be in the JS world. You are right that people including developers are often lazy and dumb, but my view is that that's actually a good reason for them to use code that is known to work rather than try to rewrite it. Keep in mind that the dumb and lazy people who might mindlessly use a bot to update their deps are the same ones who, in the absence of a 3rd party library, would mindlessly copy-pasta chunks of code from stackoverflow without checking what it actually does. Not really any better. Yes, it's not 100% guaranteed that no piece of malware can get through into a Rust project. But experience shows that this keeps happening to C-projects (mostly) and JS projects (somewhat), not so much Rust (at least so far). Of course this also reflects the fact that until recently, security-sensitive system components were almost always written in C or C++ to that made those languages the preferred targets. Still, it's a fact.

Also, you keep bringing it around to dependencies I agree with. Yes, I agree that the Rustls guys shouldn't implement their own RNG, nor their own memory buffer wipeout. Those are not <100 LoC and have hidden complexities. The issue I take is with dependencies trees that eventually go down to "isOdd" 3-line pieces of code that are basically boilerplate and have 0 complexity. People just want to "save lines of code" and avoid doing it themselves.

I don't know about isOdd. One of the smallest and probably simplest crates in Rust is once_cell (which rustls uses). There is nothing particularly difficult or complex about it. But when you are working on something which *is* difficult and complex, like rustls, you don't want to be sidetracked all the time by problems that have nothing to do with what your actual project is. Another one is simple_logger. Again, it's emphatically not rocket science, but when working on a project, no-one wants or should have to dive into the logger APIs to implement them. It also doesn't matter how many lines a crate is, but how well reviewed and tested it is.

It should also be kept in mind that Rust is a little bit like Python, but for the opposite reasons. Python famously wants you to use 3rd party packages because "the standard library is where packages go to die". In Rust, the standard library has such extremely high standards and barriers to entry that many things that other languages include out of the box (random number generators, advanced IO operations, specialised data structures etc.) are not part of it. In fact, a good chunk of crates.io is to Rust what Boost is to C++: an unofficially official extension that everyone knows and uses and some of which gets merged in bit by bit. I'm thinking of things like itertools, anyerror, clap, serde, log etc.