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

ha, the Rust fanboys and their "memory-safe"...

Just say it's a Rust implementation instead of going about it about like this.

Most languages are memory safe. Literally every language with a GC is. C and C++ are pretty much the only 2 languages that are not memory safe by default.

Go is famously not memory safe. Not only can you trivially create data races, if you data race on an interface fat pointer then you can corrupt its vtable (entirely in "safe" code; no `unsafe.Pointer`).

It is of course better at memory safety than C and C++, but these issues do come up in real deployments.

Good thing Go has a race detector!

and C++ doesn't?

Data races aren’t memory unsafe. The vtable thing is, but at least that’s accidental.

Data races have nothing to do with memory safety. Please do not conflate these two. Java, C#, Go, etc. can all have data races, but they are all memory safe languages.

Golang permits safe code to use a data race to cause type confusion and violate memory safety though.

Go is memory safe, data races are inherent to all languages beside Rust? As for interface fat pointer it's a none issue in real life code.

https://research.swtch.com/gorace

"Only 2" is very short-sighted, there's also Assembler, Pascal, Ada, Objective-C...

One general comment: it's kind of funny to see a C library being bashed right away at V1.0. As far as I can tell, nghtpp2 isn't even a CVE nest to begin with [1]. Some people must be desperate for "easy" targets.

[1] https://www.cvedetails.com/vendor/15772/Nghttp2.html

I’ve never written a line of Rust in my life. Though as a user of computers I have an interest in software being secure, especially an HTTP client which I may at some point be subject to. I’ve been a developer for a long enough time, worked with enough developers, and written enough C (not much), to have formed the strong belief that: C’s typical use is not memory-safe due to completely understandable human error, these footguns do not justify its use in most greenfield contexts, and any developer that denies the existence of these footguns has bought into a delusion that I can’t even begin to understand.

I don’t care if it’s Rust or something else. The fact that this completely legitimate and long-proven drawback of C is always met with “Rust fanboy!” comments speaks volumes, and not about ‘Rust people’. It’s incredibly disappointing that this is where we’re at with these sorts of discussions. Comments that essentially amount to “fake news!” and reject any premise of a shared reality.

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

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.

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.

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.

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.