Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Rust

josephg.com

Post reply on HN
Print view View original

281–290 of 410 posts

Re: Rewriting Rust

#281

Post by vlovich123 »

pornel wrote: post #270
josephg wrote: post #178

Earlier quoted context omitted.

Author here. If I compile a package which has 1000 transitive dependencies written by different authors, there's ~1000 people who can execute arbitrary code on my computer, with my full user permissions. I wouldn't even know if they did. That sounds like a massive security problem to me. All it would take is one popular crate to get hacked / bribed / taken over and we're all done for. Giving thousands of strangers th…

Rust can't prevent crates from doing anything. It's not a sandbox language, and can't be made into one without losing its systems programming power and compatibility with C/C++ way of working. There are countless obscure holes in rustc, LLVM, and linkers, because they were never meant to be a security barrier against the code they compile. This doesn't affect normal programs, because the exploits are impossible to wr…

There’s two different attack surfaces - compile time and runtime.

For compile time, there’s a big difference between needing the attacker to exploit the compiler vs literally just use the standard API (both in terms of difficulty of implementation and ease of spotting what should look like fairly weird code). And there’s a big difference between runtime rust vs compile time rust - there’s no reason that cargo can’t sandbox build.rs execution (not what josephg brought up but honestly my bigger concern).

There is a legitimate risk of runtime supply chain attacks and I don’t see why you wouldn’t want to have facilities within Rust to help you force contractually what code is and isn’t able to do when you invoke it as a way to enforce a top-level audit. Even though rust today doesn’t support it doesn’t make it a bad idea or one that can’t be elegantly integrated into today’s rust.

Re: Rewriting Rust

#282

Post by josephg »

pornel wrote: post #270
josephg wrote: post #178

Earlier quoted context omitted.

Author here. If I compile a package which has 1000 transitive dependencies written by different authors, there's ~1000 people who can execute arbitrary code on my computer, with my full user permissions. I wouldn't even know if they did. That sounds like a massive security problem to me. All it would take is one popular crate to get hacked / bribed / taken over and we're all done for. Giving thousands of strangers th…

Rust can't prevent crates from doing anything. It's not a sandbox language, and can't be made into one without losing its systems programming power and compatibility with C/C++ way of working. There are countless obscure holes in rustc, LLVM, and linkers, because they were never meant to be a security barrier against the code they compile. This doesn't affect normal programs, because the exploits are impossible to wr…

> the exploits are impossible to write by accident, but they are possible to write on purpose.

Can you give some examples? What ways are there to write safe rust code & do nasty things, affecting other parts of the binary?

Is there any reason bugs like this in LLVM / rustc couldn't be, simply, fixed as they're found?

Re: Rewriting Rust

#283

Post by vlovich123 »

josephg wrote: post #242
bormaj wrote: post #225

Earlier quoted context omitted.

Are there any attempts to address this at the package management level (not a cargo-specific question)? My first thought is that the package could declare in its config file the "scope" of access that it needs, but even then I'm sure this could be abused or has limitations. Seems like awareness about this threat vector is becoming more widespread, but I don't hear much discuss trickling through the grapevine re: solu…

Not that I know of - hence talking about it in this blog post!

Package scope is typically too coarse - a package might export multiple different pieces of related functionality and you’d want to be able to use the “safe” parts you audited (eg no fs access) and never call the “dangerous” ones.

The harder bit is annotating things - while you can protect against std::fs, it’s likely harder to guarantee that malicious code doesn’t just call syscalls directly via assembly. There’s too many escapes possible which is why I suspect no one has particularly championed this idea.

Re: Rewriting Rust

#284

Post by josephg »

vlovich123 wrote: post #283
josephg wrote: post #242

Earlier quoted context omitted.

Not that I know of - hence talking about it in this blog post!

Package scope is typically too coarse - a package might export multiple different pieces of related functionality and you’d want to be able to use the “safe” parts you audited (eg no fs access) and never call the “dangerous” ones. The harder bit is annotating things - while you can protect against std::fs, it’s likely harder to guarantee that malicious code doesn’t just call syscalls directly via assembly. There’s to…

> it’s likely harder to guarantee that malicious code doesn’t just call syscalls directly via assembly.

Hence the requirement to also limit / ban `unsafe` in untrusted code. I mean, if you can poke raw memory, the game is up. But most utility crates don't need unsafe code.

> Package scope is typically too coarse - a package might export multiple different pieces of related functionality and you’d want to be able to use the “safe” parts you audited

Yeah; I'm imagining a combination of "I give these permissions to this package" in Cargo.toml. And then at runtime, the compiler only checks the call tree of any functions I actually call. Its fine if a crate has utility methods that access std::fs, so long as they're never actually called by my program.

Re: Rewriting Rust

#285

Post by kibwen »

hu3 wrote: post #234
School-Cotton wrote: post #118

Earlier quoted context omitted.

Those companies can just ban using new rust dependencies, if they want to. Writing with minimal dependencies is just as easy in rust as it is in c++

You can't "just ban" new dependencies in an ecosystem where they are so pervasive otherwise the ban becomes a roadblock to progress in no time. Sorry I have a problem with "just" word in tech.

This appears to be implying that rolling your own libraries from scratch is not a roadblock in C and C++, but somehow would be in Rust. That's a double standard.

Rust makes it easy to use third-party dependencies, and if you don't want to use third-party dependencies, then you're no worse off than in C.

Re: Rewriting Rust

#286

Post by Maken »

iknowstuff wrote: post #97
sznio wrote: post #56

Earlier quoted context omitted.

I just returned to Rust after a few years, and the syntax is even more unreadable. Half of my code is just type signatures. I don't remember it being like that back in 2016 -- it seems like the convention changed and any crate you import returns the wildest types.

On the contrary. Entire `where` blocks can now disappear thanks to notation like arg: impl Iterator

Which I honestly dislike. "where clauses" were already quite syntactically limited (there are lifetimes dependencies that the compiler understand which you cannot possibly express even using for), and now "impl Trait" is reinventing the wheel trying to catch up with where with new exotic syntax like the use clauses.

Re: Rewriting Rust

#287

Post by josephg »

mwcampbell wrote: post #268
josephg wrote: post #256

Earlier quoted context omitted.

"Pleasing to corporate sponsors" isn't what comes to mind when I think about great programming languages.

But it probably is a prerequisite for any project achieving its mission on a large scale. I'd rather have a programming language that makes a big positive impact in the security, reliability, and efficiency of software that lots of people use, than one that's aesthetically pleasing but not widely used.

C and C++ were never sponsored by large companies, and they did just fine. Zig is the same, today. (It has some small sponsors, but nothing like the corporate support of rust.)

Re: Rewriting Rust

#288

Post by [deleted] »

hiimkeks wrote: post #181

I think the first three items are "add effects, and do it right": Capabilities to IO can be done by letting IO functions interrupt and call an effect handler, and the caller can specify the effect handler and do access control in there. The whole Pin situation only exists because async/await was an afterthought and didn't work well with the existing language. async/await is an instance of effects. I'm excited to star…

[deleted]

Re: Rewriting Rust

#289

Post by josephg »

mwcampbell wrote: post #257
skavi wrote: post #172

Earlier quoted context omitted.

You really should update your post wrt the Mutex changes.

Agreed. The statement that "they more or less gave up" is simply wrong. In addition to what JoshTriplett said, they landed const initialization of Mutex, RwLock, and Condvar in 1.63. That sounds like a complete success to me.

I'll update it in the morning. (I'd do it now but its nearly midnight.)

Re: Rewriting Rust

#290

Post by kibwen »

leoedin wrote: post #153
anon-3988 wrote: post #105

Earlier quoted context omitted.

Does C++ codebases with similar features parity somehow requires less code?

There's probably a similar amount of code in the execution path, but the Rust ecosystem reliance on dependencies means that you're pulling in vast amounts of code that doesn't make it to your final application. A C++ library author is much more likely to just implement a small feature themselves rather than look for another 3rd party library for it. Adding dependencies to your library is a more involved and manual pr…

> A C++ library author is much more likely to just implement a small feature themselves rather than look for another 3rd party library for it.

This is conflating Javascript and Rust. Unlike Javascript, Rust does not have a culture of "microdependencies". Crates that get pulled in tend to be providing quite a bit more than "just a small feature", and reimplementing them from scratch every time would be needlessly redundant and result in worse code overall.

Post reply on HN