Rustls Can Now Work With Nginx Via New OpenSSL Compatibility Layer

[jacob]

You might be surprised (if you were willing to consider arguments that counter your world view). Here's the actual dependency tree, with the default features, ignoring dev-time dependencies, examples, etc:

# cargo tree
rustls v0.23.5 (/home/work/c/rustls/rustls)
├── aws-lc-rs v1.7.1
│ ├── aws-lc-sys v0.16.0
│ │ ├── libc v0.2.153
│ │ └── paste v1.0.14 (proc-macro)
│ ├── mirai-annotations v1.12.0
│ ├── paste v1.0.14 (proc-macro)
│ ├── untrusted v0.7.1
│ └── zeroize v1.7.0
├── log v0.4.21
├── once_cell v1.19.0
├── rustls-pki-types v1.5.0
├── rustls-webpki v0.102.3
│ ├── aws-lc-rs v1.7.1 (*)
│ ├── rustls-pki-types v1.5.0
│ └── untrusted v0.9.0
├── subtle v2.5.0
└── zeroize v1.7.0

Indeed, so many random deps, I recoil in horror /s

Yeah look at that. How dare they not reinvent the wheel badly with their own logging implementation? How dare they use "zeroize" for safe memory buffer wipeout (which can be trickier than one might naively think)? What do they think, that their focus should just be on implementing a TLS library, or something?

[vancha]

The dependency doesn't "suddenly" get a security issue injected into it. If you trust a given git checkout not to become "suddenly" compromised, then it's the same thing here. This has been debated many times. Rust dependencies are locked to a code checksum.

This sounds like a good idea. When you specify a dependency by version in your Cargo.toml file, does that pin the library you include to a specific commit?

[jacob]

This sounds like a good idea. When you specify a dependency by version in your Cargo.toml file, does that pin the library you include to a specific commit?

Yes. There is a file Cargo.lock that pins all your dependencies and their own dependencies.

[Daktyl198]

The dependency doesn't "suddenly" get a security issue injected into it. If you trust a given git checkout not to become "suddenly" compromised, then it's the same thing here. This has been debated many times. Rust dependencies are locked to a code checksum. If the rustls developers are satisfied that their deps have no security issue at the moment they put their release out, then the deps are safe forever for everyone until they decide to update them.

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.

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.

[oleid]

Aren't you going to ultimately be linking all the dependencies statically anyway?

No, those dependencies also include dependencies only used for testing, for creating documentation and so on.

[BreachScrambler]

... just auto-update their dependencies via bots.

Is this common? I contribute to Rust projects fairly often and dependency upgrades are manually done.

You made it seem like such devs are simultaneously lazy (by not checking dependencies) and hard-working (by bothering to setup such a bot). Which bot is that BTW?

[Daktyl198]

Is this common? I contribute to Rust projects fairly often and dependency upgrades are manually done.

You made it seem like such devs are simultaneously lazy (by not checking dependencies) and hard-working (by bothering to setup such a bot). Which bot is that BTW?

Setting up a bot is hardly any effort to add when setting up an automated build environment. As for bots, github has their own called Dependabot, but there are dozens out there that different developers prefer.

[darkonix]

Setting up a bot is hardly any effort to add when setting up an automated build environment. As for bots, github has their own called Dependabot, but there are dozens out there that different developers prefer.

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:

Automatically updating dependencies with known vulnerabilities with Dependabot security updates
Dependabot can help you fix vulnerable dependencies by automatically raising pull requests to update dependencies to secure versions.

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

[LtdJorge]

I'm all for Rust written libraries, but calling Rustls a TLS library written in Rust sounds a bit weird to me. It technically is a TLS library, but just the high level API, using one of two different Rust libraries under the hood, which themselves use a library written in C/C++ and assembly.

I prefer Rustls over OpenSSL to be honest, but I don't think you could Rustls a memory safe library when every crypto algorithm is written in assembly.

[oleid]

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.

And if you don't trust dependabot, you can simply call `cargo audit` to check your dependencies for vulnerabilities.