I have a draft of a new post on my personal block, I'd appreciate pre-reading and feedback: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
Well, I've just learned that https://crates.io/crates/attohttpc is a thing, I guess I have still more testing and writing to do
Please disregard that, looks like I will be rewriting that
I'm definitely interested in minimalist security-oriented HTTP clients
particularly ones which use rustls by default
Interesting post Shnatsel. In, "Here are two probably-exploitable bugs that are still unpatched in the latest version of libcurl: 1, 2." the second link is in a unit test so might not apply.
Good catch, thanks!
I'm re-running the test on attohttpc now, will put in the results and rewrite conclusion
Also turns out https://crates.io/crates/http_req is a thing, even has some downloads unlike the other 2 sync clients
Also I think I need a better title for this post
huh, another one
I wrote one of these but it barely works and I'd like to abandon it
There's also https://crates.io/crates/cabot
@Shnatsel ureq got a bad crev rating the first time around, has the situation gotten better since then?
Yes, I believe most points from that review are addressed
I am rewriting my article to be even more nihilistic now because I've found that none of the sync crates allow specifying a timeout for the entire request, so they're all trivial to DoS
the version you linked up there has been a fun read, good job :)
though even more nihilistic might be hard to swallow^^
(for my pet projects I used attohttpc instead of ureq based on that crev comment, maybe I should switch. but then, they're just toys, and I am not sure if I want to play type golf again until I figured out how to get a
Read trait out of the response^^)
I have run attohttpc through the same test but haven't looked at the results yet. My gripe with attohttpc is that it doesn't support rustls, only openssl or native-tls
plus it pulls in the same hand-rolled hashmap advertised as HTTP types, but I guess I can live with that
@RalfJ btw you will probably appreciate this gem:
allow(clippy::mut_from_ref) is great^^
though this does have interior mutability, so if used correctly this could avoid UB
get_mut makes no sense, does it?
&mut Rc<T> doesnt mean we can safely get mutable access to the interior.
Ah, so the
&mut T transmute in here is actually okay because they are doing this to an
Of course it makes no sense, they're trying to use a hand-rolled Cell as a RefCell
which it isn't
it's not doing such a transmute, is it? it's calling
which is the one oaky way to go from
&mut T if you can assure uniqueness
get_mut safe just seems entirely wrong, this is like
Rc::get_mut but without the check that the refcount is 1...
Yep, the entire reason why
std::Cell doesn't have
get_mut() is because you need
RefCell to guarantee uniqueness
not sure what you mean? https://doc.rust-lang.org/nightly/std/cell/struct.Cell.html#method.get_mut
hmm, let me rethink that
the thing it doesnt have is
but the thing is, actix'
Cell is an
Rc, so the
&mut doesnt mean anything
std:::Cell:get_mut makes sense, but this one doesn't
oh cool, https://crates.io/crates/cabot is actually async and uses async-std under the hood. I'll have to try that
I don't get the point of that
if that's what you want, why not
does it have significantly fewer dependencies?
surf has every async dependency under the sun, except
oh weird, I guess it's only a dev-dependency?
Here's the final draft of the article, i.e. this is what's going to be on reddit tomorrow if you don't stop me:
Proofreading is _very_ welcome.
I loved it! You wrote sever instead of server in one place, purpoise instead of purpose in another. Since you mention Go in the end, would you be able to run the same experiment with it for fun?
Thanks! I am rather tired of doing this after performing and analyzing 10+ runs, so I'll leave trying Go as an exercise to the reader.
Finalized and posted: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
Thanks for all the help!
Wow, I'm getting some high praise on Reddit! https://www.reddit.com/r/rust/comments/epoloy/ive_smoketested_rust_http_clients_heres_what_i/
Hmm, this is having some profound consequences: https://words.steveklabnik.com/a-sad-day-for-rust
I've already solicited feedback elsewhere, but I liked to note here that I'm very much open to input on how I could have done better.
I think the tone was harsh but at least it focused on the code. The harshness was compounded by the follow up from others.
For me that was the real problem. The follow up became really personal and turned into direct attacks
Doesn't mean there isn't room to improve
@Shnatsel I think your post was fair, accurate, and necessary. I don't think you are to blame.
and I'm sorry for the abuse leveled at you.
Maybe it would be a good time to talk about guidelines on how to present posts like this? We've all had issues where other developers have trouble accepting security related bug reports especially when there isn't a clear POC to come along with it. Hopefully in the future there will be others filing the bugs and writing these posts too. And guidance goes a long way then
I'm glad you brought this up too. Retrospection is such a good and healthy thing, for all of us
@centril there is very little abuse levelled at me, actually. I got called a zealot, what, once? For an article with 25,000 views that's nothing.
I am my own worst critic.
There's bound to be some abuse and negativity at these exposure levels. It's a simple matter of probability. I have elaborated on it more here: https://www.reddit.com/r/rust/comments/eq11t3/a_sad_day_for_rust/feo2eh4/
Yeah I agree wrt. "probability"
@Stuart Small I absolutely agree that we need clear guidelines on what the demarcation and contracts between safe and unsafe Rust should be. But it's already described in detail in the very first chapter of the Nomicon: https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
I was thinking more of guidelines for the community in approaching security issues than use of unsafe guidelines. The author had already made it pretty clear where he stands on unsafe use (and a few other software engineering best practices) and I don’t think more documentation of best practices would change that. I think we should look more at how we can meet maintainers where they are.
I think we’ve all run into situations where we’ve reported a vulnerability to a maintainer, company or other engineer in our org and gotten a negative reaction. Sometimes dismissal, denial or flat out hostility. It isn’t surprising. I think most engineers believe they write high quality secure code and unsurprisingly get defense when someone shows up saying otherwise. When faced with a bug report there are usually pretty clear repro steps it is easier to accept the mistake. Often security vulnerabilities don’t have those clear steps or they come with a lot of conditionals. Without POC exploit code, or POC code that relies on a situation the engineer sees as realistic, they might push back or ignore the patch.
Also there will always be libraries that don’t match what we view as proper security posture. Either they don’t care (ESR’s add a segfault handlers to silence fuzzer reports), they have other interests (willing to accept the risk of deadlocks for higher throughput ie the hyper example), not viewing the ability to trigger UB through misuse of library APIs as a library bug, or something else. It is okay if other libraries have a different threat model than we do, but when that happens we should think about how to communicate this difference to the community in a respectful way.
Part of the objection I saw several people brought up was the heavy editorialize of code quality when reviewing the libraries. Whether the criticism were right or wrong it rubbed people the wrong way. We often find ourselves diving into some of the darker, dustier parts of codebases that a lot of people can ignore and this can lead to a lot of cynicism about the code. Having that come through in writing, especially a long form piece like this, can be really hard to avoid.
To be fair, when I first read the post when you posted it in here I didn’t see a problem with the writing. I thought it was an interesting and well written article. I still don’t think it was the heart of what went wrong but it was a contributing factor.
I think out of this we can look at improving on a couple different fronts:
While part of this is problem is how bug reports are communicated, educating the community is another huge part. The lines between soundness error, UB and RCE started getting blurring in some of those comment sections because of some uninformed commenters. Some educational blog posts on fundamentals to point to could go a long way in stopping mobs forming on reddit. We take a lot of this for granted but others will find it useful.
This is one I’ve been thinking about a lot. The unsafe issues with actix have been known for a while but haven’t been communicated in the healthiest way. It became a bit of a meme on reddit which helped more users find out about it but also lead to this problem. How can we communicate something like this to the community without repeat of what happened? This will involve talking about how users evaluate dependencies. Are they checking cargo crev? What about cargo gieger? Are a series of “closed will not fix” UB issues in the tracker enough to scare people away? Do users care if their dependencies heavily use unsafe? I don’t know the answer here but have a couple ideas.
Bit of a monologue. Sorry I dropped off earlier. I literally got a page right after I sent the earlier message. Today has been weird.
Thanks for sharing your thoughts. I did not have the time to carefully read and fully understand this yet, but I will do so later.
this has been bumming me out. mostly because I feel the responses to it have been so bad. Steve's post is probably the best one...
"unsafety" seems like a red herring people are diving for enthusiastically, overlooking the real problem IMO was the mob mentality, plastering every GitHub comment with emoji, etc
but everyone is rushing to have a hot take where they identify their particular axe to grind as The Thing That Went Wrong
Yeah, the dogpiling seems like the real issue. And it's sadly incredibly common, basically anytime a specific github issue is on reddit/Orange Website/goes viral on twitter/etc. it seems to happen.
Github has better tools now than it did 5 years ago, but I'm not sure tooling can be a sufficient solution
I think there's an interesting question of "are there things that can be done in our unsafety work to discourage dogpiling", but I don't have an answer to that.
I totally agree. If I wanted to point to one thing it was reddit culture and moderation. I heard one idea of banning posting links to GitHub issues and I really like that idea. It's small, enforceable and would have direct impact.
I didn't want to bring any of that because it is outside the scope of this group. I think we do have things we can do to help though
That seems like a really big hammer. It's very useful to be able to share a link to an issue in response to a question someone has!
It seems like what you want, which isn't possible ATM, is links to github issues from reddit to have a mandatory backoff time before you can comment via that link. You want the roadblock to dogpiling.
I think a simple thing GitHub could do is remove the non-affirming emoji
because when people come from upboat/downboat-driven sites like Reddit or HN, they use the emoji as if they were on Reddit or HN...
That's another really big hammer, there's lots of valid use cases for those! At work we do lots of voting on things like "which snacks should we buy for the office" with github emoji. (This makes me so happy)
Maybe our snack voting is less important :-)
That isn't really what I want. It is an idea that I saw thrown out that makes sense but I don't know what is best on the moderation front. There is a working group for that and it'll be best to leave that to them.
For me to boils down to one question, what can we do to help prevent mobs forming over security issues?
FWIW, it seems like this may all have a happy ending after all: the new maintainer of Actix has reached out to us about fixing the unsoundness and filing RustSec issues for it
Happy is... relative. The old maintainer being driven out of open source makes this bittersweet at best
I'm just glad something good could come of it