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

171–180 of 210 posts

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

#171

Post by pcwalton »

quotemstr wrote: post #55
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…

I'm still annoyed that the Rust people screwed up error handling so badly. The designers should have gone with classical exceptions like other languages, but instead went for a fashionable-at-the-time combination of error codes and added exceptions (spelled "panics"), cribbed for some reason from Go. And on top of that, the Rust designers copied one of the most annoying parts of the C++ ecosystem: a compiler switch f…

If Rust had gone with exceptions, we'd have lost the entire embedded community. You have to realize that -C panic=abort was added in no small part because of a hostile fork of the language that removed the unwinding mechanism.

I happen to like exceptions in principle, but for a lot of low-level embedded code they're a deal breaker.

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

#172

Post by MauranKilom »

kingkilr wrote: post #23
hpb42 wrote: post #21

I've heard a lot about Rust's "safety" things. But what are they? How does it compare with modern C++?

Rust has a few interlocking behaviors that provide its memory safety, a few of the most important are: - The borrow checker enforces mutable XOR shared references. - The compiler does not allow use of local variables before they're assigned to, requires structs to be completely initialized, etc.. - All the builtin datastructures perform bounds checks - The compiler disallows deferencing raw pointers except in unsafe…

Not that I consider the overall sentiment of the linked article wrong, but this...

> Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). Dereferencing a nullopt however, gives you an uninitialized value as a pointer, which can be a serious security issue.

...betrays a complete lack of understanding what Undefined Behavior is/implies. That's not something you want to see in an article discussing memory safety.

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

#173

Post by jdright »

tick_tock_tick wrote: post #154
jdright wrote: post #117

Earlier quoted context omitted.

This. Take even CURL as an example, try to list its dependencies and you'll see how harder it is.

libc that's it. Every other dependency for curl is optional.....

Try it. If you do not use any "optional" dependency it becomes pretty limited, almost useless for anything serious (eg. zlib, ssl)

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

#174

Post by mikepurvis »

skohan wrote: post #139
ordu wrote: post #122

Earlier quoted context omitted.

I think that it is the right tool. 1. CURL without https seems insufficient nowadays. 2. CURL could be improved by running multiple downloads at once. I'm not sure that curl command line utility could do it, but certainly libcurl.so has this ability, it allows client code to work with multiple connections. 3. Any application having UI could benefit from async: input/output and main task are async by nature. For examp…

1. So as to your first point, I totally agree CURL needs to support HTTPS. My point is that Hyper needs a runtime for HTTPS, and it doesn't necessarily make sense for CURL to have a runtime. 2. I'm not sure that CURL should necessarily support multiple concurrent downloads. It could also be argued it's more UNIX-y to make it just do one thing and allow the caller to run multiple CURL processes at the same time 3. You…

One better than multiple parallel downloads, aria2 can even be a long-running daemon process that does downloads on demand via a websocket API: https://aria2.github.io/manual/en/html/aria2c.html#rpc-inter...

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

#175

Post by danielheath »

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…

IMO "how many packages are the dependencies broken into" is a far less useful question than "how many maintainers have commit access to the dependency subtree".

The latter is a better question because:

* It's directly connected to your security posture. * It's a stable metric across languages with different norms about module size.

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

#176

Post by tialaramex »

svnpenn wrote: post #119
hirako2000 wrote: post #96

Earlier quoted context omitted.

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.

You dont have to use OpenSSL. For example Windows already includes Schannel, so you can build cURL with Schannel and avoid OpenSSL: https://daniel.haxx.se/blog/wp-content/uploads/2020/09/curl-...

So this gets you also different behaviour that may be what you want, or may not, depending.

Specifically if you use SChannel, you get the CA roots from Microsoft's CA Root programme, whereas ordinarily you'll end up with (some derivative of) the Mozilla CA root programme.

You also get the local policy root overrides. So for example in many corporate networks with a middlebox ensuring employees don't look at porn, the middlebox is trusted according to Windows Group Policy. Now your Curl program works the same way as Internet Explorer does, if the site is trusted in IE then it's trusted in Curl.

On the other hand, this means that the SChannel enabled Curl trusts different things from the Curl on platforms with OpenSSL. Maybe this new setup works "fine" in SChannel Curl, but only when you try from a Linux do you discover that your new site doesn't work at all any more without Microsoft's trust list, which explains the thousands of new tickets filed by (mostly Linux using) customers whose product just mysteriously broke even though it looked fine on your Windows test machine and you've just closed a dozen of those tickets as WORKSFORME...

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

#177

Post by a1369209993 »

steveklabnik wrote: post #89
ori_b wrote: post #85

Earlier quoted context omitted.

Saying "The people complaining are right, but they've been right a long time" isn't a great endorsement of the situation.

I mean, you're just repeating a sibling comment, but if development has been this way for a long time, it's on the folks who are suggesting the new way to get out there and prove that it's a viable model for software development. It appears that most real-world, actually used software works like this. I am all about improving the world, don't get me wrong, but saying "hey this software works just like all the other s…

> saying "hey this software works just like all the other software" isn't really the insult that you seem to think that it is.

Well, it's common knowledge that most existing software is compete and utter crap, as evidenced by the fact that our first thought upon hearing that a particular piece of software is no longer being updated is not "oh good, it is (probably) finished and we can rely on it", but rather "on no, now the innumerable defects no doubt still latent in it will remain unfixed". So "this software is just as bad as all the other software" is, while not a very grave insult in a relative sense, still quite damning in absolute terms.

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

#178

Post by Groxx »

steveklabnik wrote: post #113
InfiniteRand wrote: post #112

Earlier quoted context omitted.

How does Rust handle errors coming out of library operations? Is the main application able to override the panic handling behavior of a library?

Libraries can declare "I require semantic x or semantic y." Applications can as well. If an application says it needs semantic x, and a library says it requires semantic y, you get a compile error. Most libraries do not depend on a particular semantic, in my experience.

I assume library authors can specialize code to either semantic as well, and carefully target both in a single library? E.g. with cfg attributes/macros.

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

#179

Post by a1369209993 »

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, [...]

Part of the problem is that it's actually two different error cases: A, the data we're operating on is too large, versus B: the system as a whole doesn't have enough memory. Case A is obviously[0] a explicitly-handle error (just like "the data we're operating on is malformed"), whereas case B is obviously a just-give-up error (like "the system doesn't have a floating-point unit"). But there doesn't seem to be any practical way to reliably distinguish the two cases, and it's not clear they can be rigorously separated even in principle.

0: we might decide to 'handle' it by aborting, but that's not special to allocation

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

#180

Post by sk2020 »

geodel wrote: post #138
ori_b wrote: post #85

Earlier quoted context omitted.

Saying "The people complaining are right, but they've been right a long time" isn't a great endorsement of the situation.

It seems to me Rust folks have developed this habit of deflecting blame by pointing to shallow commentary. One of good examples is compiler slowness reasons, sometimes its LLVM, or it is lot of optimizations, or it is not really slow compare to C++ and so on. They could have said it straight "Guys highly optimized, safe compilation of medium size project will be in range of 20-30 min". And that would great and honest…

Rust core leadership treats most technical problems as marketing problems.
Post reply on HN