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

Bugs Rust won't catch

corrode.dev

Post reply on HN
Print view View original

301–310 of 395 posts

Re: Bugs Rust won't catch

#301

Post by dapperdrake »

safercplusplus wrote: post #210
collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

I don't know if you're aware, but there is a demonstration of wget (a fellow "gnu utility", right?) being auto-translated to a memory-safe subset of C++ [1]. Because the translation essentially does a one-for-one substitution of potentially unsafe C elements with safe C++ counterparts that mirror the behavior, the translation should be much less susceptible to the introduction of new bugs and behaviors in the way a r…

Filesystem access is mostly treated by users as serialized ACID transactions on "files in directories."

"Managing this resource centrally" is where unix syscalls came from. An OS kernel can be used like a specialized library for ACID transactions on hardware singletons.

People then got fancy with virtual memory, interrupts, signals, time-slicing, re-entrancy, thread-safety, and injectivity.

It doesn’t matter, whether you call the "kernel library" from C, C++, Fortan, BASIC, Golang, bash, Rust, etc.

Re: Bugs Rust won't catch

#302

Post by dapperdrake »

dapperdrake wrote: post #26
collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

First of all, thank you for presenting a succinct take on this viewpoint from the other side of the fence from where I am at. So how can I learn from this? (Asking very aggressively, especially for Internet writing, to make the contrast unmistakable. And contrast helps with perceiving differences and mistakes.) (You also don’t owe me any of your time or mental bandwidth, whatsoever.) So here goes: Question 1: How com…

Additional point:

The point of data storage is to be a singleton.

(Backups are desireable, anyhow.)

Re: Bugs Rust won't catch

#304

Post by streetfighter64 »

> That means, even if the tools were (and probably still are) buggy, they never had a bug that could be exploited to read arbitrary memory.

Well, that begs the question, is it worse to read arbitrary memory (which would probably in most cases be prevented by various dynamic protections [0] anyway), or failing to prevent rm -rf /./ and killing every process in the system, etc.?

This is still a good case study of the value of the much-touted rust rewrites. Usually they are performed by people who are domain experts in rust, but (as seen here) lack basic domain knowledge of the tool's environment.

[0] https://en.wikipedia.org/wiki/Buffer_overflow_protection

Re: Bugs Rust won't catch

#305

Post by bcjdjsndon »

alfiedotwtf wrote: post #279
bcjdjsndon wrote: post #262

Earlier quoted context omitted.

> No, this is completely incorrect, Show me system level rust code that only uses safe then... You can't because its impossible. I doesn't matter that it's a minority of files (!), the simple fact is you can't program systems without using unsafe. Rewrite the c dependencies in rust and the amount of unsafe code increases massively > Most Rust coders are not manually managing memory on the regular Another sidestep. If…

I think you’re deliberately being obtuse here, and if you don’t see why, you should probably reflect on your reasoning. I’ve been using Rust for about 12 years now, and the only times I’ve had to reach for `unsafe` was to do FFI stuff. That’s it. Maybe others might have more unsafe code and for good reasons, but from my perspective, I don’t know wtf you’re talking about.

> Maybe others might have more unsafe code and for good reasons, but from my perspective, I don’t know wtf you’re talking about

"well I don't need to use unsafe that much so I don't know what your point is" sounds like you don't really have an answer.

Re: Bugs Rust won't catch

#306

Post by dapperdrake »

kibwen wrote: post #155
greatgib wrote: post #139

Earlier quoted context omitted.

The rewrite in Rust is mostly vanity and marketing but not based on a real technical need... So I don't see why they would want to do that.

Canonical's usage of uutils is likely for marketing. But the codebase itself was developed for fun, as an excuse for people to have a hands-on way to learn Rust back before Rust was even released, with a minor justification as being cross-platform. From the original README in 2013: Why? ---- Many GNU, linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to window…

Isn't this how Kernighan and late Ritchie (K&R) ended up with unix and C?

Honestly, brilliant guys.

When C got its own standards committee they even rejected Ritchie's proposal to add fat pointers to C before it was too late to add them. Instead, we got the C abstract machine.

Re: Bugs Rust won't catch

#307

Post by dapperdrake »

PunchyHamster wrote: post #171
kibwen wrote: post #155

Earlier quoted context omitted.

Canonical's usage of uutils is likely for marketing. But the codebase itself was developed for fun, as an excuse for people to have a hands-on way to learn Rust back before Rust was even released, with a minor justification as being cross-platform. From the original README in 2013: Why? ---- Many GNU, linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to window…

>Canonical's usage of uutils is likely for marketing Currently their usage is actively worsening the security of their distro

Welcome to building something new.

Re: Bugs Rust won't catch

#308

Post by dapperdrake »

gzread wrote: post #177
collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

I see even the coreutils maintainers find themselves needing -n (no newlines) and -c (count) options to "yes".

GNU coreutils is known for adding command libe options.

One of the big philosophical differences to the BSD's.

For a human being, it sucks both ways.

Re: Bugs Rust won't catch

#309

Post by dapperdrake »

Dr_Emann wrote: post #47
cyberax wrote: post #34

Earlier quoted context omitted.

To be fair, Vec::set_len bug in Rust was in 2021. And even then it had to be annotated as `unsafe`. It was then deprecated and a linter check was added: https://github.com/rust-lang/rust-clippy/issues/7681

To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.

> well behaved readers.

Around and around we go.

Re: Bugs Rust won't catch

#310

Post by dapperdrake »

KnuthIsGod wrote: post #170
kibwen wrote: post #156

Earlier quoted context omitted.

If you don't want Canonical's packages, you should probably just be using Debian rather than Ubuntu. It's not 2008 anymore, stock Debian is quite user-friendly.

Or use a sane distribution like Arch or Gentoo instead of Ubuntu based systems.

Alpine Linux has a better shot at acceptable compile times.

Some FOSS software seems to maximize kernel IO last time I had a Gentoo.

Post reply on HN