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

291–300 of 410 posts

Re: Rewriting Rust

#291

Post by amluto »

josephg wrote: post #189
lifthrasiir wrote: post #174

Earlier quoted context omitted.

> Why not? I believe you are proposing a language-based security (langsec), which seemed very promising at first but the current consensus is that it still has to be accompanied with other measures. One big reason is that virtually no practical language implementation is fully specified. As an example, let's say that we only have fixed-size integer variables and simple functions with no other control constructs. Inte…

> As an example, let's say that we only have fixed-size integer variables and simple functions with no other control constructs. Integers wrap around and division by zero yields zero, so no integer operation can trap. So it should be easy to check for the infinite recursion and declare that the program would never trap otherwise, right? No! A large enough number of nested but otherwise distinct function calls would e…

I think what you’re saying is that, in fully safe code, control flow can’t have any surprises other than panics and/or signals/exceptions. I think this is true. And I would love to use a language that limited side effects like this at the language level — even ignoring security, it makes reasoning about code easier.

The issue of build-time security is somewhat separate, and it actually seems easier to tackle strongly. There have been proposals floated around to make proc macros use wasm and run in a sandbox, and IMO Rust should absolutely move in this direction.

Re: Rewriting Rust

#292

Post by Maken »

SkiFire13 wrote: post #112
throwup238 wrote: post #89

Earlier quoted context omitted.

The graveyard of features in nightly is actually pretty big. Important stuff like specialization is forever stuck there.

AFAIK many of those language features (specialization included) are blocked by the rewrite of the trait solver.

I think there is a bigger issue with specialization, and it's that nobody seems to agree in what the semantics should be. The orphan rules are clearly artificially limiting, but there is no formal description of a new set of rules to replace them, only proposals.

Re: Rewriting Rust

#293

Post by josephg »

dgroshev wrote: post #273
josephg wrote: post #151

Earlier quoted context omitted.

Author here. Thanks for the in depth response. I appreciate hearing an insider's perspective. > I always find it amusing to see, simultaneously, people complaining that the language isn't moving fast enough and other people complaining that the language is moving too fast. I think people complain that rust is a big language, and they don't want it to be bigger. But keeping the current half-baked async implementation…

> But keeping the current half-baked async implementation doesn't make the language smaller or simpler. It just makes the language worse. I can't disagree more. In fact, I think that the current state of async Rust is the best implementation of async in any language. To get Pin stuff out of the way: it is indeed more complicated than it could be (because reverse compatibility etc), but when was the last time you need…

> In fact, I think that the current state of async Rust is the best implementation of async in any language.

Hahahaha hard disagree. Last year I implemented the braid protocol (a custom streaming protocol using HTTP) in javascript in less than an hour and about 30 lines of code. Then I spent 2 weeks trying to do the same thing in rust - writing hundreds of lines of code in the process and I couldn't get it to work. Eventually I gave up.

I got it working recently - but only by borrowing some wild tricks from reading the source code of tokio, that I never would have thought of on my own.

> To get Pin stuff out of the way: it is indeed more complicated than it could be (because reverse compatibility etc), but when was the last time you needed to write a poll implementation manually?

Last week, while writing a simple networked database application. Again I needed to produce an async stream, and thats impossible using async fn.

Re: Rewriting Rust

#294

Post by binary132 »

When I look at the way C++ has been developed and implemented over the years, I can’t help but think that a relatively small and questionably sustainable group of compiler engineers, no matter how passionate (and people do burn out) cannot possibly hope to sustain development of Rust indefinitely, especially as the project’s complexity and convolutions continue to further complicate and convolve. The only reason C++ has been able to is that it has very extensive industrial sustenance behind at least two of its major compilers, and presumably they also help keep GCC up to par. I don’t know, maybe GCC can somehow set the standard for what Rust can hope to do over the years, but it seems like a minor miracle from the outside.

Re: Rewriting Rust

#295

Post by sacado2 »

johnisgood wrote: post #231
bjackman wrote: post #92

Rust isn't an Exciting New Language any more. It's in the "work towards widespread adoption" phase. Slower feature development is natural and healthy, the stakes are high, mistaken design choices are much more harmful than low velocity at this point. I'm not excited about Rust because of cool features, I'm excited because it's a whole new CLASS of language (memory safe, no GC, production ready). Actually getting it i…

Is it really a new class of language considering we had Ada / SPARK for ages? It takes safety further, too, with formal verification.

It also has range types, avoiding a whole class of bugs.

Re: Rewriting Rust

#296

Post by steveklabnik »

josephg wrote: post #282
pornel wrote: post #270

Earlier quoted context omitted.

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?

https://github.com/Speykious/cve-rs

They can be fixed, but as always, there’s a lot of work to do. The bug that the above package relies on has never been seen in the wild, only from handcrafted code to invoke it, and so is less of a priority than other things.

And some fixes are harder than others. If a fix is going to be a lot of work, but is very obscure, it’s likely to exist for a long time.

Re: Rewriting Rust

#297

Post by vlovich123 »

josephg wrote: post #284
vlovich123 wrote: post #283

Earlier quoted context omitted.

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 u…

> Hence the requirement to also limit / ban `unsafe` in untrusted code

I think you’d be surprised by how much code has a transitive unsafe somewhere in the call chain. For example, RefCell and Mutex would need unsafe and I think you’d agree those are “safe constructs” that you would want available to “utility” code that should haven’t filesystem access. So now you have to go and reenable constructs that use unsafe that should be allowed anyway. It’s a massively difficult undertaking.

Having easier runtime mechanisms for dropping filesystem permissions would definitely be better. Something like you are required to do filesystem access through an ownership token that determines what you can access and you can specify the “none” token for most code and even do a dynamic downgrade. There’s some such facilities on Linux but they’re quite primitive - it’s process wide and once dropped you can never regain that permission. That’s why the model is to isolate the different parts into separate processes since that’s how OSes scope permissions but it’s super hard and a lot of boilerplate to do something that feels like it should be easy.

Re: Rewriting Rust

#298

Post by jasode »

josephg wrote: post #287
mwcampbell wrote: post #268

Earlier quoted context omitted.

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

>C and C++ were never sponsored by large companies,

I don't know what you had in mind for "sponsored" but others would disagree and say both C and C++ were "sponsored by AT&T Bell Labs" because the people who created them (Dennis Ritchie, Bjarne Stroustrup) were employees of AT&T. Analogous to Rob Pike, et al. of Go Language being employed/sponsored at Google.

Re: Rewriting Rust

#299

Post by SkiFire13 »

DanielHB wrote: post #237
SkiFire13 wrote: post #107

Earlier quoted context omitted.

For 1), Cargo already take care of that if you use the same major version. Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. This means that if a bundled dependency in the stdlib is even found to have some design issue that require breaking changes to fix then you're out of luck. As you said the stdlib could deprecate the old version and add a new one, but then you're j…

> Cargo already take care of that if you use the same major version. Most dependency management systems do that, but large projects often end up pulling multiple different major versions of (often very large) dependencies. > 2) worse by forcing everyone to include the old deprecated dependency too! Like I said I am no expert on Rust, but I assume that Rust can eliminate stdlib dead-code from the runtime? So unused de…

> > Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible. > > Yes, which is a feature. For example Go is very annoying about this not only on the stdlib. https://go.dev/doc/go1compat a lot of 3rd party libs follow this principle as well.

But there's no reason such a "feature" requires bundling dependencies in the stdlib. As you mention 3rd party Go libs manage to do this perfectly fine.

> but I tend to think that the stdlib should be fairly big and tackle most common problems.

I tend to disagree with this, because the way to tackle those common problems with likely change in the future, but the stdlib will be stuck with it for eternity. I would rather have some community-standard 3rd party crate that you can replace in the future when it will grow old. See also "Where modules go to die" https://leancrew.com/all-this/2012/04/where-modules-go-to-di...

Post reply on HN