Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safe ‘curl’ for a more secure internet

daniel.haxx.se

Post reply on HN
Print view View original

101–110 of 210 posts

Re: Memory safe ‘curl’ for a more secure internet

#101

Post by skohan »

svnpenn wrote: post #32

I like this idea, but I dont know if Hyper is the best package to go with. Hyper occupies part of the Rust ecosystem that I think suffers from package bloat, like much of NPM. For example, currently Hyper requires 52 packages: autocfg, bitflags, bytes, cfg-if, fnv, fuchsia-zircon, fuchsia-zircon-sys, futures-channel, futures-core, futures-sink, futures-task, futures-util, h2, hashbrown, http, http-body, httparse, htt…

I also wonder if Hyper is really the right tool for the job here. When I was looking into HTTP/S crates, I decided against Hyper because it seemed to require bringing in a runtime for HTTPS, and the async nature of hyper did not seem necessary for my totally synchronous CLI tool. For something like CURL it seems like you would just want the leanest, simplest synchronous HTTP implementation possible

Re: Memory safe ‘curl’ for a more secure internet

#102

Post by steveklabnik »

quotemstr wrote: post #99
steveklabnik wrote: post #90

Earlier quoted context omitted.

Again, I am only speaking of logic bugs here. You cannot introduce memory safety bugs without unsafe code. > I don't think I'm ever going to convinced that the error handling wasn't a huge and unfixable mistake. That's fine. No language can satisfy everyone.

Logic bugs can be just as disastrous as memory safety bugs. From an attacker's point of view, they're ultimately about making a program do something not intended. Downplaying logic bugs (where Rust is weak) and emphasizing memory safety (where Rust is strong) might make Rust look better, but it's not doing any favors for computing.

I agree that they can be. There are a few differences:

1. It is not clear that we will ever be free of logic bugs to the same degree that we can minimize memory safety bugs.

2. We're in a specific context in this sub-thread, and that's that you claimed that this is a pervasive issue that everyone must consider all the time. These logic bugs can only be introduced in a context that is very unusual, and so my claim is not that logic bugs in general are irrelevant, but that the context that this kind of bug can appear is smaller than you say it is.

> logic bugs (where Rust is weak)

Rust gives you way more tools than C to reduce logic bugs as well.

Re: Memory safe ‘curl’ for a more secure internet

#103

Post by quotemstr »

steveklabnik wrote: post #102
quotemstr wrote: post #99

Earlier quoted context omitted.

Logic bugs can be just as disastrous as memory safety bugs. From an attacker's point of view, they're ultimately about making a program do something not intended. Downplaying logic bugs (where Rust is weak) and emphasizing memory safety (where Rust is strong) might make Rust look better, but it's not doing any favors for computing.

I agree that they can be. There are a few differences: 1. It is not clear that we will ever be free of logic bugs to the same degree that we can minimize memory safety bugs. 2. We're in a specific context in this sub-thread, and that's that you claimed that this is a pervasive issue that everyone must consider all the time. These logic bugs can only be introduced in a context that is very unusual, and so my claim is…

The whole point of secure programming is caring about those "unusual" contexts. And the comparison to C isn't really fair: C is dangerous for everything. Yes, Rust is better than C, and even better in some ways than C++, but my point is that there's another Rust out there, a Rust^, that's even better than Rust, and Rust^ uses exceptions for error handling throughout.

Re: Memory safe ‘curl’ for a more secure internet

#104

Post by the8472 »

cle wrote: post #83
nine_k wrote: post #37

Earlier quoted context omitted.

All these packages provide important pieces of functionality, which, I suppose, mostly cannot be omitted. Either you depend on other's work for that, or you roll your own. Choose your poison.

There’s a third option if the package is so important: put it in the standard library. Technically it’s still a dependency but the standard library is maintained with a standard that is rarely matched by third party libraries, and can dramatically simplify the ecosystems’ dependency graph.

Rust's standard library is intentionally kept small since it's initially not always obvious what the best solution is and the stability guarantee makes it the wrong place for evolving, diverse or opinionated APIs.

E.g. the async ecosystem offers you to pick between runtimes of different complexity and tradeoffs. Std only picked up the essential traits that allow other crates to interoperate with each other and the language itself to define async functions.

Re: Memory safe ‘curl’ for a more secure internet

#105

Post by brundolf »

steveklabnik wrote: post #43
bluejekyll wrote: post #31

Earlier quoted context omitted.

This quote is interesting: “ I’m a bit vague on the details here because it’s not my expertise, but Rust itself can’t even properly clean up its memory and just returns error when it hits such a condition. Clearly something to fix before a libcurl with hyper could claim identical behavior and never to leak memory”. So Rust aborts on invalid memory accesses, unwrap on None, etc. It does not abort on memory leaks. I do…

> So Rust aborts on invalid memory accesses, unwrap on None, etc. Rust will panic on these things, and panics can abort, or unwind. Unwind is the default. That's not what's being talked about here, I don't think. This is about alloc::alloc::handle_alloc_error, which was not allowed to unwind at the time the linked comment was made. But in the last few hours, https://github.com/rust-lang/rust/pull/76448 was linked to,…

This is an interesting case for error-handling, because a) it can happen virtually anywhere, so handling it with Result would add huge API overhead in terms of ergonomics (given that most code never really has to think about it), yet b) it's very important that it is able to be handled in certain kinds of system contexts, which panics are not designed to facilitate. Most error cases seem to fall neatly into one camp or the other (something you always want to explicitly handle, or something where you just want to abort), but this one doesn't.

handle_alloc_error seems to do well enough as a workaround, but (from my superficial reading of the GitHub thread) it feels like just a very specific "poor-man's try/catch" for this one particular case. It feels like a workaround.

In general I'm a big fan of Result/panic in place of traditional exceptions, but this usecase makes it really quite unideal

Re: Memory safe ‘curl’ for a more secure internet

#106

Post by steveklabnik »

brundolf wrote: post #105
steveklabnik wrote: post #43

Earlier quoted context omitted.

> So Rust aborts on invalid memory accesses, unwrap on None, etc. Rust will panic on these things, and panics can abort, or unwind. Unwind is the default. That's not what's being talked about here, I don't think. This is about alloc::alloc::handle_alloc_error, which was not allowed to unwind at the time the linked comment was made. But in the last few hours, https://github.com/rust-lang/rust/pull/76448 was linked to,…

This is an interesting case for error-handling, because a) it can happen virtually anywhere , so handling it with Result would add huge API overhead in terms of ergonomics (given that most code never really has to think about it), yet b) it's very important that it is able to be handled in certain kinds of system contexts, which panics are not designed to facilitate. Most error cases seem to fall neatly into one camp…

> This is an interesting case for error-handling, because

I think this is a very good articulation of this space, thank you.

> It feels like a workaround.

I agree, but the needed work to improve this has taken a very, very, very long time, and so I think workarounds are ultimately helpful. We'll get there...

Re: Memory safe ‘curl’ for a more secure internet

#107

Post by dang »

sohkamyung wrote: post #13

Here's what Daniel Stenberg had to say about the move [1] [1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

I guess we'll change the URL to that from https://www.abetterinternet.org/post/memory-safe-curl/, since the blog post has at least some technical detail. Thanks!

Re: Memory safe ‘curl’ for a more secure internet

#108

Post by weinzierl »

hirako2000 wrote: post #96
monadic2 wrote: post #81

Earlier quoted context omitted.

Thinking about crates this way is a revelation to me. Is there any tooling to make analyzing dependencies as you did easier?

That. And then we become responsible for yet more possible vulns in all those deps. Current number of cURL deps: 14 I wish it relied only on OpenSSL.

Not depependin on OpenSSL is kind of the point of the original post if I understand it correctly.

Also I find the dependency on OpenSSL one major pain in my Rust projects. When you want to build a statically linked binary you need to supply a statically built OpenSSL and if your distro doesn't come with one (like Ubuntu) you are on your own. Yes, there is a Docker container that comes with all the prerequisites but I think that's a bit heavy for my purposes.

I wish there was a single switch in Cargo.toml and every dependency would automagically use rustls.

Re: Memory safe ‘curl’ for a more secure internet

#109

Post by johnisgood »

Kednicma wrote: post #5

You can't get memory safety by picking a language with `unsafe` blocks. I appreciate the sentiment but the implementation details are important here; I'd take this more seriously if they picked something like OCaml instead of Rust.

Not only that, but to write anything more than a hello world requires lots of unsafe blocks. There are loads of them everywhere, in all of those crates, incl. the standard library.
Post reply on HN