Rust-Written Rustls Now Reportedly Outperforming OpenSSL & BoringSSL

[oleid]

Oh. If only you knew... 😂 It will probably be a while before the 8051 grows wings and can fly with some Rust code anyway... (Looks like there is some experimental AVR branch though )

Is there even GCC or LLVM support for 8051? Oo

The only thing I found during a 1 min search was an Assembler for 8051 written in rust xD

[Developer12]

Is a 3044 lines long dependency file acceptable? That alone makes me question its ability to provide security.

And of course it also pulls in OpenSSL as a dependency too. Nice!

I'm sorry, would you prefer that the dependencies weren't tracked at all? Every large C++ project out there (including OpenSSL!!!) embeds countless dependencies "vendored" in it's source tree, but C/C++'s total lack of a dependancy managment and packaging system makes this impossible to track consistently. You don't SEE those dependencies, but they're there.

And then one of those dependencies of a C++ project has a vulnerability and all those vendored copies of it's code don't get updated because developers have forgotten it's even there. Any modern language (rust, python, js, etc, etc, etc) with dependency tracking automatically grabs the fixed version or at the very least alerts you that there's a problem. Only C/C++, with their roots in the bad old days of the 1970's when people shared source tarballs on tapes, haven't caught up.

Oh, and did you not actually read the file you're linking to? You might have noticed there are *checksums* in there too, so that the versions to can be locked to those which have been inspected/audited.

[unwind-protect]

The benchmark for this library, is that from a C or Rust program?

I assume it is from the commandline utility shipped with OpenSSL and its equivalent for the Rust library - so a Rust program.

Then I am curious how much throughput you lose if you plug the Rust library into a "legacy" C application.

[ssokolow]

Then I am curious how much throughput you lose if you plug the Rust library into a "legacy" C application.

I suspect none at all. Rust was specifically designed so there's no big mismatch for FFI to paper over and the places where translation would potentially need to occur (eg. Rust's default string type is counted instead of null-terminated) probably won't apply since this would be manipulating byte buffers and you can hand back and forth between Rust types like Vec<u8>/&[u8] and C char arrays at effectively zero cost using .as_ptr()/.as_mut_ptr() and .len() or slice::from_raw_parts()/slice::from_raw_parts_mut().

(I say "effectively" because I'm not sure if the optimizer can reliably and entirely eliminate the two movs to the (*data, len) stack struct that a slice is when calling from_raw_parts/from_raw_parts_mut... though you can always optimize that by not using slice if your profiler says it's actually a measurable problem.)

It's basically the same as FFI-ing between C and C++.

[Veto]

Is there even GCC or LLVM support for 8051? Oo

The only thing I found during a 1 min search was an Assembler for 8051 written in rust xD

The 8051 has some severe limitations (e.g. stack size and lack of registers) that makes it unfit for use with normal C code. Any Rust compiler would be seriously limited (and IMHO not worth the effort) Please use a newer CPU!

The AVR is probably the only 8-bit architecture that is designed to be somewhat useful with modern compilers. However you would be crazy to start a new design using an 8-bit CPU today...

[kpedersen]

I'm sorry, would you prefer that the dependencies weren't tracked at all? Every large C++ project out there (including OpenSSL!!!) embeds countless dependencies "vendored"

"Countless" and yet still a tiny fraction compared to Rust projects. Tracking isn't the problem. I am stating that Rust projects tend to to pull in dependencies carelessly. C and C++ projects are much less inclined to do so. OpenSSL is a good example of that.

And then one of those dependencies of a C++ project has a vulnerability and all those vendored copies of it's code don't get updated because developers have forgotten it's even there.

It doesn't work like that. Dependencies can be updated fine whether tracked or not. Perhaps you struggle because you pull in 1000+ dependencies for a "hello world" program? Then sure. Good luck, thats a "you" problem.

Oh, and did you not actually read the file you're linking to? You might have noticed there are *checksums* in there too, so that the versions to can be locked to those which have been inspected/audited.

That file contains lots of info. Thats why it is good evidence that as a typical Rust project, it has a terrible number of dependencies. Not quite sure as to what you are confused about.
Are you saying that the file "only contains checksums" and no other information about the daft number of dependencies? In which case clear your browser cache, and try downloading the file again.

[Almindor]

I wouldn't say it's more dangerous than plain C, though, since C leaves as much freedom, if not more, and programmers are on their own to manage ownership, which they don't all do the same way (so collaborative projects may see a mix of methods). Assembly doesn't check anything and is the lowest level, so it's obviously the least safe, by far. But yes, unsafe depends more on the programmer than the rest of the code. Normally, a Rust developer should already be more careful, but it's still tricky indeed, especially when allocating and freeing memory. I see no Miri validation flow, but I haven't checked in the dependencies.

Anyway, there's very little unsafe used in this library, though it's not as much documented as it should. I would be more concerned about the alpha stage of it (it's only 0.23) and the dependencies (some of which are very alpha, too). There are a number of issues, and the code hasn't been exposed as much as the library it wants to replace, and the compiler can only do so much to guarantee safety.

Coincidently https://chadaustin.me/2024/10/intrus...-list-in-rust/ was just published and I think it shows what I'm talking about very nicely.

[ssokolow]

"Countless" and yet still a tiny fraction compared to Rust projects. Tracking isn't the problem. I am stating that Rust projects tend to to pull in dependencies carelessly. C and C++ projects are much less inclined to do so. OpenSSL is a good example of that.

The algorithms need to be implemented somewhere. Do you really think it's going to be safer to roll your own linked list or MD5 implementation (in a memory-unsafe language, no less) than to sha256sum-pin an implementation with multiple downstream projects caring about its trustworthiness and infrastructure for disseminating RUSTSEC advisories?

(The Rust ecosystem also has cargo-supply-chain which tells you your exposure as a list of contributors instead of a list of pieces they chose to split your dependencies into... a metric which would get rid of the false sense of security you get from monolithic dependencies like Boost, OpenSSL, etc.)

[Unscript]

Coincidently https://chadaustin.me/2024/10/intrus...-list-in-rust/ was just published and I think it shows what I'm talking about very nicely.

Thanks for the link! Looks like an interesting read for this weekend.

Come to think of it, there's also the fact the Rust compiler makes assumptions than the C compiler doesn't, which could be surprising indeed.

[Developer12]

"Countless" and yet still a tiny fraction compared to Rust projects. Tracking isn't the problem. I am stating that Rust projects tend to to pull in dependencies carelessly. C and C++ projects are much less inclined to do so. OpenSSL is a good example of that.

Have you LOOKED at the OpenSSL source tree recently?

C/C++ devs COMPULSIVELY copy code into their projects from elsewhere, just like everyone else. They all visit stack overflow, they all copy+paste code from other projects. Nobody bothers to write their own code snipped for padding strings they copy it from stack oveflow, but at the very least node.js devs were honest about where they got it from.

It doesn't work like that. Dependencies can be updated fine whether tracked or not. Perhaps you struggle because you pull in 1000+ dependencies for a "hello world" program? Then sure. Good luck, thats a "you" problem.

Yeah, right buddy. Because Every C/C++ developer remembers every bit of C code they randomly copied into some random source file or function to just "do a thing."

That file contains lots of info. Thats why it is good evidence that as a typical Rust project, it has a terrible number of dependencies. Not quite sure as to what you are confused about.
Are you saying that the file "only contains checksums" and no other information about the daft number of dependencies? In which case clear your browser cache, and try downloading the file again.

Have you looked at the dependency trees up-thread? There are 11 total, 3 of which are transitive and two of which come from the same project and are simply split into separate repos.

OpenSSL on the other hand includes in all kinds of bullshit for everything from crypto and compression algorithms to protocol crap. It's just baked into the source tree so nobody even remembers where it came from. The best hint you'll get is usually a weird copyright or licence header.