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

161–170 of 210 posts

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

#161

Post by pixel_fcker »

brundolf wrote: post #114
steveklabnik wrote: post #106

Earlier quoted context omitted.

> 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...

I think it can honestly be traced down to just how wide a stretch of usecases Rust itself has managed to span. For systems, this arguably is "something you always want to explicitly handle", whereas for applications it's almost always "something where you just want to abort". The level of abstraction is very different, but a single language is spanning both. Or, more precisely, a single standard library. Just spitbal…

This is AFAICT essentially what wg-allocators is working on where you can directly specify an allocator in collections (and alloc() returns a Result): https://github.com/TimDiekmann/alloc-wg

From the readme it sounds like this has actually started to be upstreamed now?

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

#162

Post by deckard1 »

jandrese wrote: post #145
svnpenn wrote: post #64

Earlier quoted context omitted.

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…

> other languages have this problem too, so deal with it This is the primary reason I try to avoid projects built with npm. Fucking dependency hell. If the project hasn't been actively maintained in the last 3 months your chances of getting it to work drop precipitously.

Github and npm are both graveyards filled with dead JS libraries. They make it too easy to litter the universe with sub-par orphaned software. And somehow, it's up to each individual to filter it all out. You have critical software such as React sitting next to mountains of bad nonsense code. And they are all on equal footing.

People love to trash Perl on HN. But among many other things that Perl devs understood, they deeply understood issues that come up with dependencies. Most CPAN modules are namespaced, have unit tests, and unit tests run when modules are installed. Not only that, the people behind CPAN understood that it is a community effort and you, as a library author, have certain responsibilities to your community.

https://pause.perl.org/pause/query?ACTION=pause_04about

None of that exists in npm. We have scopes in npm, and that's about it. CPAN makes npm look like a child's toy.

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

#163

Post by geodel »

staticassertion wrote: post #159
geodel wrote: post #138

Earlier quoted context omitted.

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…

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.

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

#164

Post by ncmncm »

steveklabnik wrote: post #144
ncmncm wrote: post #136

Switching immediately to building with C++, and then migrating incrementally to safe forms in C++, would provide much more value per unit effort. It would also enable engagement by the orders-of-magnitude more available skilled C++ programmers, who could also pick up new skills writing modern, safe C++ to apply in other migrations. It is not an either/or proposition. Certain, select modules could be recoded in Rust b…

I think you may have misunderstood what the post is saying they're going to do. It is significantly more in line with your suggestion than you seem to think.

I might have misunderstood. But if so, good!

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

#165

Post by nextaccountic »

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.

Currently the mpsc channel on the stdlib is worse than the one found on crossbeam (according to the author[0]). That's one data point.

[0] https://internals.rust-lang.org/t/scaling-back-my-involvemen...

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

#166

Post by mitchtbaum »

I'm unifying Rust's async HTTP implementations H1, H2, H3 and Google's tarpc in Rust~Actix~Torchbear. I just don't have a lot of time now sice my house got broken and I don't have enough money to rent anywhere. It also needs a lot of work on the parsing layer, and the laptops with my notes on them are hard to keep with me as I move around.

https://github.com/google/tarpc

https://github.com/actix/actix-web/tree/master/actix-http/sr...

https://github.com/hyperium/h2

https://github.com/djc/quinn/tree/main/quinn-h3

https://github.com/speakeasy-engine/torchbear/blob/master/sr...

~

There's beauty in this with the fluency in which complex applications like the coming secure social network, Radiojade, are built. See this example:

!# https://github.com/foundpatternscellar/ping-pong/blob/master...

Curl users, do you really want to stick with Bash's syntax instead of this??

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

#167

Post by cle »

steveklabnik wrote: post #143
cle wrote: post #135

Earlier quoted context omitted.

I agree, there's no silver bullet, only tradeoffs and our appetites for them. From looking at the list of crates above, I see a lot that are often part of the stdlib of other languages, such as HTTP, concurrency/nio primitives, and logging. My perception of Rust's not including such fundamental primitives in the standard library is that Rust is still very much experimental, and the ecosystem values tinkering and expe…

HTTP libraries are a prime example of where many, many standard libraries are considered old and crufty, and there are much better ecosystem libraries that end up being wildly used more. You may have that perception, and that is fine, but it's not likely to be a thing that changes significantly, even when Rust is quite old. There's just not a lot of advantage to being in the standard library, and numerous downsides.

We should be more nuanced than that. There are also many standard libraries where the HTTP implementation is the standard. Why?

> There's just not a lot of advantage to being in the standard library, and numerous downsides.

Look at those huge lists of dependencies and the complaints of Cargo dependency hell. That's the downside. Every node in your dependency graph has overhead for everyone involved, and it's even worse when it's something as fundamental as HTTP.

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

#168

Post by steveklabnik »

cle wrote: post #167
steveklabnik wrote: post #143

Earlier quoted context omitted.

HTTP libraries are a prime example of where many, many standard libraries are considered old and crufty, and there are much better ecosystem libraries that end up being wildly used more. You may have that perception, and that is fine, but it's not likely to be a thing that changes significantly, even when Rust is quite old. There's just not a lot of advantage to being in the standard library, and numerous downsides.

We should be more nuanced than that. There are also many standard libraries where the HTTP implementation is the standard. Why? > There's just not a lot of advantage to being in the standard library, and numerous downsides. Look at those huge lists of dependencies and the complaints of Cargo dependency hell. That's the downside. Every node in your dependency graph has overhead for everyone involved, and it's even wor…

Yes, there are downsides to every approach here. That's just life.

I write a lot of Rust that never touches HTTP.

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

#169

Post by steveklabnik »

ncmncm wrote: post #164
steveklabnik wrote: post #144

Earlier quoted context omitted.

I think you may have misunderstood what the post is saying they're going to do. It is significantly more in line with your suggestion than you seem to think.

I might have misunderstood. But if so, good!

Yes, curl has a concept of "backends," which you can choose at compile time. This is about providing an option for a new backend, based on Rust libraries. That's it. Nobody is re-writing anything.

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

#170

Post by ameixaseca »

I like how the comment referenced in the article with the description "Rust itself can't even properly clean up its own memory" was answered today saying the restriction of unwinding on oom is going away; it's not a fundamental issue, just something that wasn't implemented that way the first time.
Post reply on HN