6 ms·

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

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

codewiz 3y ago
C API: https://github.com/cloudflare/quiche/blob/master/quiche/include/quiche.h https://github.com/cloudflare/quiche/blob/master/quiche/incl...
mgaunard 3y ago
[flagged]
- adgjlsfhk1 3y ago
  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.
  - tczMUFlmoNk 3y ago
    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.
    - zakkor1 3y ago
      Good thing Go has a race detector!
      - mgaunard 3y ago
        and C++ doesn't?
    - dontlaugh 3y ago
      Data races aren’t memory unsafe. The vtable thing is, but at least that’s accidental.
    - mseepgood 3y ago
      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.
      - anonymoushn 3y ago
        Golang permits safe code to use a data race to cause type confusion and violate memory safety though.
    - Thaxll 3y ago
      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 https://research.swtch.com/gorace
  - astrobe_ 3y ago
    "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 https://www.cvedetails.com/vendor/15772/Nghttp2.html
- 3c6bYDXLMj 3y ago
  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.
  - mgaunard 3y ago
    [flagged]
zik 3y ago
quiche may be great - I haven't tried it - but it definitely isn't memory safe. It uses unsafe constructs liberally.
- mcronce 3y ago
  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
  - zik 3y ago
    By that reasoning C is also memory safe.
    - mcronce 3y ago
      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.
- josephg 3y ago
  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.
  - nine_k 3y ago
deleted 3y ago
[deleted]
nonameiguess 3y ago
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.
- codewiz 3y ago
  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 https://github.com/cloudflare/quiche#curl
  - torstenvl 3y ago
    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.

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

codewiz 3y ago

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

mgaunard 3y ago

[flagged]

adgjlsfhk1 3y ago
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.
- tczMUFlmoNk 3y ago
  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.
  - zakkor1 3y ago
    Good thing Go has a race detector!
    - mgaunard 3y ago
      and C++ doesn't?
  - dontlaugh 3y ago
    Data races aren’t memory unsafe. The vtable thing is, but at least that’s accidental.
  - mseepgood 3y ago
    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.
    - anonymoushn 3y ago
      Golang permits safe code to use a data race to cause type confusion and violate memory safety though.
  - Thaxll 3y ago
    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 https://research.swtch.com/gorace
- astrobe_ 3y ago
  "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 https://www.cvedetails.com/vendor/15772/Nghttp2.html
3c6bYDXLMj 3y ago
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.
- mgaunard 3y ago
  [flagged]

zik 3y ago

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

mcronce 3y ago
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
- zik 3y ago
  By that reasoning C is also memory safe.
  - mcronce 3y ago
    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.
josephg 3y ago
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.
- nine_k 3y ago

deleted 3y ago

[deleted]

nonameiguess 3y ago

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.

codewiz 3y ago
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 https://github.com/cloudflare/quiche#curl
- torstenvl 3y ago
  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.