Hacker News Reader

Comment by codewiz | Hacker News Reader

How about using a memory-safe HTTP/3 implementation which is also callable from C or any other language? https://github.com/cloudflare/quiche

View on HN

Why does discussion always have to devolve into this? This isn't an advertisement asking brand-new greenfield projects to base their work on C libraries. This work is done because it's an update to nghttp2 to add support for HTTP/3. The reason you would use it is because you're already using nghttp2 and want to know about the added features. The list of tooling using nghttp2 is pretty extensive, including at bare minimum the Apache web server and curl, which collectively likely initiate at least a plurality of the Internet's HTTP traffic because of their age and ubiquity.

Why are these tools written in C? Because they're old. nghttp2 was released in 2009, before Go was released and before Rust was even a twinkle in its eventual creators' eyes. Adding comments like this any time a feature announcement to a C library is made comes across like you're saying nobody should ever update tools that are already in use. Should Linux just stop doing work until the kernel is rewritten from the ground up in Rust? Should all longstanding software take a five-year pause to do total from-scratch rewrites? Can you see why that is impractical? If you can, then you can see why libraries like nghttp2 exist and continue to add features.

The title of this post puts emphasis on "written in C", making me wonder when this would ever be a desirable feature, given that more secure implementations are available, and can be integrated into old C projects just as easily.

No need to rewrite everything from the ground up: https://github.com/cloudflare/quiche#curl

Just stop. It is not a requirement for you to wage holy wars against languages you dislike. In fact, as a form of "ideological battle," it's against the Guidelines.

C API: https://github.com/cloudflare/quiche/blob/master/quiche/incl...

quiche may be great - I haven't tried it - but it definitely isn't memory safe. It uses unsafe constructs liberally.

That doesn't mean it's not memory safe - it means that those constructs need to be thoroughly scrutinized for memory safety, which is significantly better than the entire codebase needing to be thoroughly scrutinized for memory safety

By that reasoning C is also memory safe.

No? Your entire C codebase needs to be thoroughly scruitinized, whereas in Rust, you can build a small portion with unsafe code, thoroughly audit that, and build a sound abstraction on top.

What does “liberally” mean here? Because without even looking at the code, I bet less than 5% of the code in quiche is unsafe. It’s probably about 2% or something. And remember, unsafe rust is still borrow checked and often run through Miri as well - which is crazy strict. Miri rejects a lot of correct programs.

There is no comparison with C, where trivial programs exhibit UB and memory unsafety all the time, and the standard library is covered in foot guns.

I really dislike the puritan wing of the rust community who see the unsafe keyword as some sort of blight to be excised. Unsafe is a necessary and important part of the language. It is needed for lots of reasons - like how you can’t make high performance container types in purely safe rust. Or to interact with code written in other languages.

Unsafe is not a devils mark. It’s a good and useful tool. Get over it.

It often suffices to find one remotely triggerable unsafe memory write in a huge executable to achieve RCE.

Memory safe would be 0% unsafe.

“n% unsafe” here refers to `unsafe` blocks that can’t be automatically guaranteed safe by the Rust compiler, not to actual concrete instances of memory unsafety.

Right. And even if you only work in “safe rust”, a massive part of the software stack you rely on still isn’t formally verified like that. LLVM and rustc aren’t formally verified - and they likely have bugs. The kernel is all “unsafe” code. And the rust standard library is full of unsafe code. And so on. Moving heaven and earth to excise the last 2% of unsafe code in random rust libraries just doesn’t make engineering sense. Especially when doing so comes with a significant performance cost.

If reliability is what you’re after, that time is almost certainly better spent adding more tests, fuzz testing and validating your code with Miri and friends.

Examples, tests and interfacing with C are almost all the instances of unsafe.

I assumed the FFI would be the unsafe bit, you can't interact with an unsafe language from a safe context - the mere act of dereferencing a pointer that originates from unsafeland is fraught with UB.

Reply on news.ycombinator.com