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

81–90 of 210 posts

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

#81

Post by monadic2 »

nicoburns wrote: post #50
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…

Part of this is just crates being broken up more in Rust. For example the `http` crate only contains trait (interface) definitions. They break down like so: Platform integration: libc, winapi, winapi-build, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, ws2_32-sys, fuchsia-zircon, fuchsia-zircon-sys, kernel32-sys, redox_syscall Primitive algorithms: itoa, memchr, unicode-xid Proc macro / pinning utilities:…

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

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

#82

Post by Tankenstein »

brundolf wrote: post #72
faitswulff wrote: post #12

Earlier quoted context omitted.

And a credit to the author of cURL as well: > We’d like to thank Daniel for his willingness to be a leader on this issue. It’s not easy to make such significant changes to how wildly successful software is built, but we’ve come up with a great plan and together we’re going to make one of the most critical pieces of networking software in the world significantly more secure. We think this project can serve as a templa…

> one of the most critical pieces of networking software in the world cURL is widely available and widely used, obviously, but I'm surprised to see it described this way. I've always seen it mainly as a way for people and scripts to conveniently try out endpoints and download files. But this makes it sound like more than that; does it get widely used in an infrastructural capacity?

I remember from very old PHP days that the default http client everyone reached for in PHP land was curl: https://www.php.net/manual/en/book.curl.php . I don't doubt that this is the case for many other older languages as well. This means, in turn, that there are large swathes of the internet communicating with one another via methods like this.

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

#83

Post by cle »

nine_k wrote: post #37
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…

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.

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

#84

Post by qchris »

count wrote: post #49
kingkilr wrote: post #39

Earlier quoted context omitted.

While I don't love the proliferation of dependencies, from a risk perspective the raw number of dependencies isn't always the right metric. Looking at the authors and publishers numbers from https://github.com/rust-secure-code/cargo-supply-chain it's clear a lot of these are maintained by the same set of trusted folks.

This is true today, will it remain true?

It's also worth pointing out that once a version is published to crates.io, it can't be altered, specifically to prevent social engineering attacks. If you're worried about it, that means you can audit the frozen codebase for any given version from a top-level crate down through the dependencies, and once that trust is established, it can't be leveraged for a silent dependency change later on, which can only happen through a version update on the end-user's side.

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

#85

Post by ori_b »

steveklabnik wrote: post #38
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…

https://wiki.alopex.li/LetsBeRealAboutDependencies > These complaints are valid, but my argument is that they’re also not NEW, and they’re certainly not unique to Rust ... The only thing new about it is that programmers are exposed to more of the costs of it up-front.

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

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

#86

Post by seg_lol »

est31 wrote: post #57
seg_lol wrote: post #51

Earlier quoted context omitted.

I count 67 --> 42 (after removing the dev only deps) https://gist.github.com/seg-lol/0d22cf5002f890305cfd094f9ed1... *edit, passed in -e no-dev to `cargo tree`, thanks @est31 for the suggestion

The number is smaller than that. You need to pass -e no-dev to cargo tree to filter out the dev-dependencies (which are only relevant for hyper development).

Thanks!

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

#87

Post by tialaramex »

bagder wrote: post #54
tialaramex wrote: post #33

Earlier quoted context omitted.

Historically there was a long period where this didn't do what you expect, which is very bad. What this looks like it does, and indeed does today (modulo bugs some of which could be prevented using Rust) is: Ask totally-not-evil.example.com for this install.sh resource and then run that as root as a Bash script. This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a flopp…

"For some years" sure, but that's ancient history. curl has verified the server certificates by default since version 7.10, shipped in October 2002.

I'm actually just very old. But thanks for the effort put into Curl over all this time.

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

#88

Post by quotemstr »

steveklabnik wrote: post #71
steveklabnik wrote: post #58

Earlier quoted context omitted.

> The overall result is that everyone pays the cognitive cost of exception (spelled "unwind" in Rust) safety Very, very few people have to think about unwind safety, because it really only comes into play when you're writing unsafe code, and relying on the ability for panics to be caught. Many folks aren't writing any unsafe, and many who are are doing it explicitly in a panic=abort environment. And most don't rely o…

Okay so, technically in theory you can introduce logic bugs, but not memory safety bugs, if you don't consider unwind safety in safe code. Logic bugs can happen in any code, of course. The practical, day-to-day implications of this still round to zero, though.

> The practical, day-to-day implications of this still round to zero, though.

Vendors have been using similar language to downplay potential bugs for decades, usually to disastrous results. At one point, even memory safety wasn't a big deal. I'm just waiting for a software package to have a security vulnerability when an attacker is able to trigger an untested Rust unwind path and put some Rust daemon into a state it didn't expect.

There are many good parts of Rust, but I don't think I'm ever going to convinced that the error handling wasn't a huge and unfixable mistake. It's because error handling is such a big mistake that Rust has grown layers of syntactic sugar --- try!, !, etc. --- to paper over the ugly spot in the language.

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

#89

Post by steveklabnik »

ori_b wrote: post #85
steveklabnik wrote: post #38

Earlier quoted context omitted.

https://wiki.alopex.li/LetsBeRealAboutDependencies > These complaints are valid, but my argument is that they’re also not NEW, and they’re certainly not unique to Rust ... The only thing new about it is that programmers are exposed to more of the costs of it up-front.

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 software" isn't really the insult that you seem to think that it is.

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

#90

Post by steveklabnik »

quotemstr wrote: post #88
steveklabnik wrote: post #71

Earlier quoted context omitted.

Okay so, technically in theory you can introduce logic bugs, but not memory safety bugs, if you don't consider unwind safety in safe code. Logic bugs can happen in any code, of course. The practical, day-to-day implications of this still round to zero, though.

> The practical, day-to-day implications of this still round to zero, though. Vendors have been using similar language to downplay potential bugs for decades, usually to disastrous results. At one point, even memory safety wasn't a big deal. I'm just waiting for a software package to have a security vulnerability when an attacker is able to trigger an untested Rust unwind path and put some Rust daemon into a state it…

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.

Post reply on HN