Rustls Can Now Work With Nginx Via New OpenSSL Compatibility Layer

[Daktyl198]

Exactly. If you want to state that "Rust is bad", just go for the dependencies in the rusttls cargo.lock file.

That is a lot of dependencies haha, get that shite out of here.

That's less "rust bad" and more "Modern programmers are bad and lazy". That many dependencies aren't needed, but they can't be bothered writing 100 loc themselves.

[mdedetrich]

That's less "rust bad" and more "Modern programmers are bad and lazy". That many dependencies aren't needed, but they can't be bothered writing 100 loc themselves.

Or maybe its more that a lot of C programmers having Dunning–Kruger effect where they think they are smarter than everyone else so they have NIH syndrome where they end implementing something themselves and end up getting something really wrong.

The rust way of doing things with libraries + vetting means that you have greater assurance of software quality, not less.

[Daktyl198]

Or maybe its more that a lot of C programmers having Dunning–Kruger effect where they think they are smarter than everyone else so they have NIH syndrome where they end implementing something themselves and end up getting something really wrong.

The rust way of doing things with libraries + vetting means that you have greater assurance of software quality, not less.

It's fine to pull in dependencies that make sense. Libraries exist for a reason. But pulling in 200 dependencies just shouldn't be necessary on any project, let alone one as "small" as this one. Especially since, as I mentioned, many of those "dependencies" are 100 LoC or less and easily re-implemented yourself. And how many dependencies do those 200 dependencies call in?

JavaScript/node.js development has poisoned the mind of modern developers. It's "isOdd" all over again.

[access]

The lock-file contains all dependencies recursively. The Cargo.toml files specifies the projects immediate deps.

[darkonix]

Currently nginx executable is about 1.46MB.
So now big is that binary with compatibility layer?

Originally you wanted to compare the compatibility layer only with nginx. Now you want to compare rusttls + compatibility layer? what would it prove? As someone mentioned it would be more apple to apples to compare with openssl.

[nanonyme]

The lock-file contains all dependencies recursively. The Cargo.toml files specifies the projects immediate deps.

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

[jacob]

It's fine to pull in dependencies that make sense. Libraries exist for a reason. But pulling in 200 dependencies just shouldn't be necessary on any project, let alone one as "small" as this one. Especially since, as I mentioned, many of those "dependencies" are 100 LoC or less and easily re-implemented yourself. And how many dependencies do those 200 dependencies call in?

JavaScript/node.js development has poisoned the mind of modern developers. It's "isOdd" all over again.

It's 200 dependencies total, including everything that's called in. The project itself has only 9 deps, one of them is temporary (once_cell) until it gets upstreamed into the std library.

BTW using a dependency for a 100 LoC routine is GOOD (if it's a reputable and reviewed dependency of course). Even very short code can and often does contain footguns and pitfalls that one is not even aware of unless they thought about it long and hard. Which obviously people usually don't, especially the r34L pr0gr4Mm3Rz types. In this case, I much prefer the developers to focus all their attention on getting the crypto API right and not be distracted with the problems of handling dates, logging safely with correct output encoding, async IO etc.

[moltonel]

just go for the dependencies in the rusttls cargo.lock file.

That is a lot of dependencies haha, get that shite out of here.

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

[Daktyl198]

It's 200 dependencies total, including everything that's called in. The project itself has only 9 deps, one of them is temporary (once_cell) until it gets upstreamed into the std library.

BTW using a dependency for a 100 LoC routine is GOOD (if it's a reputable and reviewed dependency of course). Even very short code can and often does contain footguns and pitfalls that one is not even aware of unless they thought about it long and hard. Which obviously people usually don't, especially the r34L pr0gr4Mm3Rz types. In this case, I much prefer the developers to focus all their attention on getting the crypto API right and not be distracted with the problems of handling dates, logging safely with correct output encoding, async IO etc.

Every dependency is a piece of code you do not control. The implementation could break, become worse, or suddenly have a security issue injected into it. The fewer dependencies you can get away with, the better.

[jacob]

Every dependency is a piece of code you do not control. The implementation could break, become worse, or suddenly have a security issue injected into it. The fewer dependencies you can get away with, the better.

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.

And you know what, it's much better if every piece of code is controlled by someone who is responsible for that particular piece of code. Who do you think is more likely to produce say a better random generator: someone who understands random generators, has experience with them, knows what could go wrong and, most importantly, whose project it is to implement and maintain a random generator? Or someone whose project is something totally unrelated, just happens to need a random number at some point, doesn't know about random number generation and just uses some quick'dirty hack to get it done?

The idea that better software results if you "control" everything is incredibly naive and at the same time denotes dangerous hubris.