[HN Gopher] Would Rust Secure Curl?
___________________________________________________________________
Would Rust Secure Curl?
Author : todsacerdoti
Score : 70 points
Date : 2021-01-16 21:15 UTC (1 hours ago)
(HTM) web link (timmmm.github.io)
(TXT) w3m dump (timmmm.github.io)
| [deleted]
| IgorPartola wrote:
| I really should learn Rust. I am just nostalgic for C because C
| makes me feel like I am doing something closer to what the CPU
| works with. I know there are several layers underneath all that,
| but with C you can do all manner of dangerous things that by any
| means you shouldn't be allowed to do. I have used it for a few
| projects over the years but lately the only place I really get
| into it is programming Arduinos or similar. I am sure sooner or
| later we will get a good toolkit for a language that both does
| proper memory management AND can allow you to do all the things
| you can do with C on a microcontroller, but so far I haven't seen
| that.
|
| Also, I have it on my TODO to go back and redo the Capture the
| Flag challenges from like 10 years ago that dealt with things
| like stack overflows. I had a ton of fun working on those and it
| would be fun to revisit them. Anyone got a modern version of
| something like that?
| amelius wrote:
| The problem with security in Rust is that the language emphasizes
| the reduction of memory bugs. The resulting code then creates an
| increased cognitive load which can make other bugs more likely.
|
| Therefore, use Rust if you really have to. Otherwise, tools like
| automated garbage collection are a much better way to reduce the
| likelihood of bugs.
| Blikkentrekker wrote:
| _Rust 's_ type system with regards to _C_ and that of many
| other languages certainly helps to avoid logic bugs as well.
|
| A simple difference would be that, for instance, in _Java_
| every object is nullable, whereas in _Rust_ , this is only so
| when it be declared as such and the type system requires one to
| in some capacity first verifiy of a nullable type that it isn't
| null before something meaningful can be done with it.
| cryptoquick wrote:
| The cognitive load this is just temporary. I can say that after
| writing it full-time for about half a year, and dabbling in and
| out of it for a bit longer, I've gotten as good with Rust as I
| was with JS or TypeScript.
|
| I've seen people learn Rust as their first programming
| language, and it fills me with joy that the next generation of
| programmers won't have to build up this vault of apocryphal
| knowledge I've had to over the years. Or, at least, not the
| same one. And hopefully not as large.
|
| I've also found Rust to be a very pleasant application
| development language. As a former NodeJS developer, I've been
| able to replace Express with Warp and Electron and React with
| Iced. It's not ready for all things, but it's ready for a heck
| of a lot. And the question of "what's possible" has broadened
| so much due to work by the community in even just the past
| year, I really think the majority of all other applications,
| including web frontend (cargo web), servers, desktop apps
| (iced), and mobile apps (cargo mobile), can be reasonably
| implemented in most part entirely in Rust within only a few
| years.
| [deleted]
| creata wrote:
| > the language emphasizes the reduction of memory bugs
|
| That's not really true: Rust's borrowing and ownership apply to
| most kinds of in-program resource ownership and aliasing, not
| just memory.
|
| > The resulting code then creates an increased cognitive load
| which can make other bugs more likely.
|
| I'm not saying you're wrong, but I'd like to see any evidence
| for this. Personally, I'd expect the opposite to be true:
| knowing whether any given object is non-exclusively borrowed,
| exclusively borrowed, or owned at any point in the program
| sounds like very useful documentation for people reading the
| code.
| jstimpfle wrote:
| From skimming some Rust code now and then, it seems to me
| that Rust programs look completely different at least. While
| C programs focus on creating simple data structures and
| getting the task done with as few memory operations as
| possible, in Rust I've dominantly seen use of types,
| memory/resource safety patterns and external libraries. My
| theory is that this removes direct understanding what happens
| and instead shifts the focus on how to get the task done
| while not violating the type system rules. In both cases,
| what the programmer minimizes in the first place might be the
| lines of code or maybe "code complexity". (Assuming
| programmers tend to do what most directly leads to completion
| of the programming task).
|
| I'm not in a position to claim that this theory is actually
| true, and I won't take a stance which is "better", but
| personally the former is much more appealing to me, for
| purely aesthetic reasons.
| cryptoquick wrote:
| Rust provides a good balance between performance,
| correctness, and ergonomics. It's called the "Goldilocks
| language", because it's not too slow, it's not too unsafe,
| and it's not too difficult.
|
| Also, much of the tooling I used to add to projects in
| other languages is either built-in and commonly used (test,
| fmt), or easily added to cargo (edit, bench, web, mobile).
| [deleted]
| viraptor wrote:
| I find this description unsatisfying. The "use of types"
| makes applications easier to understand and cleaner for
| example. Just a generous use of enums helps with some kinds
| of logic errors as well and ensures more expressive code.
| (==1 vs ==Match::Domain)
| jstimpfle wrote:
| I use enums in C, too. And the problems with C enums that
| people complain about don't apply for me. That's not what
| I mean by "use of types". What I mean by it is
| significant "programming in type language" as opposed to
| "in code language". Programming in type language I find
| unappealing because it is very indirect, implicit, and
| typically achieves very little per line of code.
| [deleted]
| viraptor wrote:
| > I use enums in C, too
|
| Enums in C are just ints with names. They're error prone
| and not type checked. You can always use 0 instead of a
| name and it will work. You can use TLSv2 instead of
| ExterminateHumans and it will also work.
|
| > What I mean by it is significant "programming in type
| language" as opposed to "in code language".
|
| I honestly don't understand what you mean by this.
| jstimpfle wrote:
| > Enums in C are just ints with names.
|
| Yes, they are integers. You can do arithmetic with them,
| you can use them as bitmasks, or use sentinels instead,
| like -1. I like that.
| capitol_ wrote:
| This seems like an unlikely claim, do you have any numbers to
| back it up?
|
| If having memory errors being compile time errors instead of
| runtime error leads to more logical errors due to complexity.
| Wouldn't that imply that using other types of complicated
| checkers also leads to more logical errors, for example static
| analysis software or valgrind?
| jcranmer wrote:
| One of the things the author neglects is the ease of use of
| newtypes in Rust. This can actually alleviate a lot of parsing
| issues, by making it impossible to use stuff without parsing.
|
| An example of where I've recently done something like this is my
| sparse linear algebra code. I have distinct types for column and
| row vectors for a matrix, so that if I want to right-multiply A
| with a vector, the input has to be a column vector and the output
| has to be a row vector. Similarly, if I want to left-multiply A
| with a vector, the input has to be a row vector and the output
| has to be a column vector.
| fortran77 wrote:
| > _Rust proponents may seem overly zealous and I think this has
| led to a minor backlash of people thinking "Rust can't be that
| great surely; these people must be confused zealots, like Trump
| supporters or Christians". But it's difficult to argue with
| numbers like these._
|
| Huh!?
| Blahah wrote:
| What part are you huh?ing at?
| dwaltrip wrote:
| It's a foolish, aggressive analogy that needlessly distracts
| from the topic at hand, regardless of any validity it may or
| may not have. There are far better ways of communicating the
| intended message.
| Yajirobe wrote:
| Christians - confused zealots?
| gameswithgo wrote:
| Well either y'all are or everyone else is....or just all of
| us.
| dwaltrip wrote:
| Either way, this is definitely not the point of the post.
| It seems worthwhile to make an effort to avoid rehashing
| highly controversial, unrelated topics -- even if the
| article accidentally baits us into it.
| hartator wrote:
| Overpolitization of everything?
| gameswithgo wrote:
| Well it was probably unwise to add that language to the essay
| even if I don't think it is wrong.
| sremani wrote:
| Huh!? I am not happy that he did not put costco shoppers in
| that list .. /s
|
| Yes, that was a needless statement that distracts but you know
| what, there is no point getting too hung up on things like
| these from readers perspective too.
| overboard2 wrote:
| Burgers?
| throwaway_2hf1 wrote:
| Leaving aside the strangely bigoted comment about religion, his
| argument about Rust securing all memory bugs is vapid. As anyone
| acquainted with high-performance networking code in Rust has seen
| (remember the Actix fallout?), it's very hard to do a great many
| things without unsafe Rust. I'd much prefer a deeper discussion
| about a) how many of these bugs are actually important in
| practice and b) how a few of them would be solved by idiomatic,
| safe Rust. This article doesn't do either and doesn't answer the
| question in its own title.
| muskox2 wrote:
| How many memory bugs of the same calibre has Actix had, even
| with the large amount of unsafe code in its codebase?
| lights0123 wrote:
| A lot of the Actix-web drama was the author refusing to replace
| unsafe code with safe code that performs equally as well. After
| the creator quit, the community took over and removed a lot of
| the unsafe code present.
| jjmartins wrote:
| Does Hacker News approve articles where the author insults
| Christians? Calling them "confused zealots"?
| curtis3389 wrote:
| > On-Topic: Anything that good hackers would find interesting.
| That includes more than hacking and startups. If you had to
| reduce it to a sentence, the answer might be: anything that
| gratifies one's intellectual curiosity.
| rat9988 wrote:
| I cannot see how you can give such an answer in good faith.
| charonn0 wrote:
| Does it really matter?
| Blikkentrekker wrote:
| I never quite understood why an ideology should be except from
| criticism so long as it be popularly called a religion.
|
| Evidently one can insult _Rust_ evangelists, why do many
| consider the arbitrary classification of "religion" so special?
| Especially when it seems a common criterion to call something a
| religion is "at least part of the belief must be provably
| false.". -- _wakarimasen lol._
| [deleted]
| depressedpanda wrote:
| I think it was unnecessary and off-topic, and the quality of
| the article suffered for it.
|
| However, the rest of the content was interesting.
| rat9988 wrote:
| Same here. The content is interesting, but he just made the
| whole things worse by insulting people.
| rvz wrote:
| I couldn't care less of it.
|
| Everyone ignores their political mini-rants or whatnot. It's
| completely irrelevant to the discussion; especially this one.
| tux3 wrote:
| >These are how I classified the bugs. If I've got something
| drastically wrong let me know.
|
| I'm really happy to see the data behind the claim! I've been
| slowly desensitized to opinions masquerading as unsourced
| supporting graphs of dubious provenance. It's so simple, but
| kudos to the author for the transparency.
|
| When Daniel wrote "C is not the primary reason for our past
| vulnerabilities", he may or may not have been right. But he sadly
| did not back that up with easily verifiable, refutable, data.
|
| Data is like a ray of sunlight. Instead of arguing high-level
| opinions, let's argue the data
___________________________________________________________________
(page generated 2021-01-16 23:00 UTC)