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

191–200 of 210 posts

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

#191

Post by johnisgood »

johnisgood wrote: post #109
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.

Moderately low-level crates require some unsafe blocks. Rust is supposed to be a systems language from what I heard, so if you are going to write something larger, and/or complicated, and/or low-level, you will have to resort to unsafe blocks, I think.

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, httpdate, indexmap, iovec, itoa, kernel32-sys, lazy_static, libc, log, memchr, mio, miow, net2, pin-project, pin-project-internal, pin-project-lite, pin-utils, proc-macro2, quote, redox_syscall, slab, socket2, syn, tokio, tokio-util, tower-service, tracing, tracing-core, try-lock, unicode-xid, want, winapi, winapi-build, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, ws2_32-sys

Without rust/library/:

    $ grep -irn 'unsafe' | wc -l
    3077
With rust/library/:

    $ grep -irn 'unsafe' | wc -l
    7854
Yep, there are indeed loads of them. Feel free to clone all of those repositories and look for those unsafe blocks. You could even get it per-crate.

Of course there are some false positives in there, and yes, some crates may not have unsafe blocks (so not all crates have them, you got me), but still... It is a bit too many unsafe blocks.

Or I do not know, maybe they just have a thing for unsafe blocks, for example in the standard library (std) you can find 2267 unsafe blocks.

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

#192

Post by steveklabnik »

Groxx wrote: post #178
steveklabnik wrote: post #113

Earlier quoted context omitted.

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.

I actually don't think so, but I'm also not sure what use case would require you to do this. Generally, you're agnostic, and only in very specific circumstances would you require unwind. I'm not sure when a library would require abort.

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

#193

Post by staticassertion »

geodel wrote: post #163
staticassertion wrote: post #159

Earlier quoted context omitted.

Your argument seems to be "people see problems and other people explain why those problems exist" and somehow you frame it like it's a bad thing.

No my point is Rust fans try to win very narrow technical arguments even when they should clearly know discussion is about big picture. And yes it seems bad thing to me.

On an internet forum when someone brings up a topic lots of people will respond with different opinions about that topic. You can act like this is somehow specific to the Rust community, but I don't think it is.

TBH you seem to have a really odd bias against Rust, you repeatedly take something about it that's positive and try to spin it as negative, like possibly even for years? Maybe examine that.

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

#194

Post by asveikau »

pjmlp wrote: post #19
mehrdadn wrote: post #6

Earlier quoted context omitted.

Oh thanks, that at least gives some idea of the potential. I see e.g. "HTTP/2 trailer out-of-bounds read" and "SSL out of buffer access"... I guess there might be some candidates.

If you start from when Morris worm got released into UNIX world, there will be plenty to chose from.

Quite a bit broader than "libcurl's HTTP/HTTPS handling", though.

Which it sounds like the answer is nonzero. But significantly smaller than "every C bug since 1988".

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

#195

Post by Measter »

johnisgood wrote: post #191
johnisgood wrote: post #109

Earlier quoted context omitted.

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.

Moderately low-level crates require some unsafe blocks. Rust is supposed to be a systems language from what I heard, so if you are going to write something larger, and/or complicated, and/or low-level, you will have to resort to unsafe blocks, I think . Hyper requires 52 packages: autocfg, bitflags, bytes, cfg-if, fnv, fuchsia-zircon, fuchsia-zircon-sys, futures-channel, futures-core, futures-sink, futures-task, futu…

One thing to bear in mind is that the libc and winapi crates are bindings to the libc and Windows C headers, so every single function signature in there will be marked unsafe because it's FFI, so those will be heavily impacting your results.

You could also avoid some false positives in comments by searching for "unsafe fn" and "unsafe {", rather than just the word "unsafe", as those are the only tokens (to my knowledge) that can follow "unsafe".

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

#196

Post by sk2020 »

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…

A quick check of cargo-Geiger shows many hundreds of unsafe invocations in the dependencies of hyper. I think it’s hard to argue that some rust HTTP library is Irrefutably safer when you’ve thrown out so many of the static guarantees of the language and replaced them with “dude, trust me”.

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

#197

Post by stjohnswarts »

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…

It's fine, how often do you have to rebuild curl?

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

#198

Post by stjohnswarts »

svnpenn wrote: post #64
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.

Hm, this response essentially says "other languages have this problem too, so deal with it". While thats true, it completely misses the point. The point is not that dependencies exist, or even that a package might have many dependencies. The point is, Rust (and NPM) I have found many times dont care or even consider the impact of a large amount of dependencies, and often take no steps to mitigate or reduce that numbe…

Can you point out any projects that have gone off the rails because of dependencies? I mean otherwise it's just "what if" syndrome.

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

#199

Post by stjohnswarts »

k__ wrote: post #63
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.

"It has always been that way." doesn't seem to be a helpful statement here.

Yes but people often throw out empty criticism without offering solutions or alternatives and it gets annoying after a while and is just a complaint rather than a healthy critique. As programmers we've heard them all before I guarantee it, so why add another one to the pile?

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

#200

Post by nicoburns »

a1369209993 wrote: post #186
tracker1 wrote: post #182

Earlier quoted context omitted.

It depends. If it's in a github repo and there isn't a massive backlog of issues for a software that hasn't been updated in a while, I might think that. One good thing about stat counters for packages combined with GitHub for issue tracking of you can kind of tell. It does take some level of die diligence and isn't easy. But neither is anything relying on say system installed libraries in C projects. I'd rather have…

Can you give even a single example of: - a significant (eg, at least as complex as wget) software project, - that has been unmaintained (no updates, code has the same MD5/etc hash), - with a significant userbase (not sure exactly how to define that one), - for a significant amount of time (at least five years), - which is generally regarded as finished and bug-free (not in need of further development) rather than aba…

TeX: https://en.wikipedia.org/wiki/TeX#TeX82
Post reply on HN