Live data from Hacker News

Bugs Rust won't catch

corrode.dev

351–360 of 395 posts

Re: Bugs Rust won't catch

#351

Thanks for the list. I like these lists, so I can put them into a .md file, then launch "one agent per file" on my codebase and see if they can find anything similar to the mentioned CVEs. Rust won't catch it, but now the agents will. Edit: https://gist.github.com/fschutt/cc585703d52a9e1da8a06f9ef93c... for anyone who needs copying this

Most (if not all) of these issues do not matter at all outside the scope GNU utils run in. For example, using filepaths instead of FDs does not matter in most cases in controlled server environments, or in processes that will never run with elevated privilege (most apps).

> Most (if not all) of these issues do not matter at all outside the scope GNU utils run in.

I suspect that attitude is how we got ourselves into this mess.

You have to assume you ultimately don't control what scope your software runs in. Obviously you do, 99.999% of the time. The other 0.0001% is when someone has found another vulnerability that lets them run your program with elevated privileges in an environment you didn't expect, and then they can use it to exploit one of these bugs. Almost all exploits use a chain of vulnerabilities each one seemingly mostly harmless - your "no one can ever exploit this weakness in my program because I control the environment" will be just one step in the chain.

That sounds far fetched. It is far fetched in the sense that it almost never happens. But nonetheless systems were and are exploited because of it. Once the solution was added in 2006 (openat() and friends), it should have never happened again. And indeed in the GNU utils it can't.

The people who build Rust's std::fs should have been aware of the problem and its solution because it was written in 2015. std::path was written at the same time, and that is where the change has to be made. It's not a big change either: std::path has to translate the path into a OS descriptor use that instead of the path - but only if it was available. I suspect the real issue was they had the same attitude as you, they thought it affects such a small percentage of programs it didn't really matter. That and it's a little bit of extra work.

It was a pity they had that attitude, because the extra work would have avoided this mess.

Re: Bugs Rust won't catch

#352
post #73

Earlier quoted context omitted.

This seems to be the case, yes. Before reading this post I was a lot more open minded about the "rewrite it in Rust" scene but now I'm just kind of in a horrorpit wondering whether I'll be stuck on macOS forever :(.

Creative but implausible excuse. MacOS is a better OS for consumers than Windows. But if you're a developer or other technical person, nothing stops you from using Linux today.

Right but coming from macOS, how do I know that the Linux distro I pick doesn't have this god-forsaken stuff in it? Before this thread I didn't know Canonical was so... busted. What else do I not know? With macOS, I think I can be sure that this kind of stuff won't be in the core shell commands :).

When I do `man builtin` on macOS now, I get:

``` HISTORY The builtin manual page first appeared in FreeBSD 3.4. ```

which is what I expected, and I don't expect those to be pulled out from under me and replaced with the sort of nonsense we have here today.

Re: Bugs Rust won't catch

#353
post #324

Earlier quoted context omitted.

Hence why even on UNIX people moved on from NFS, but on Linux it keeps being the remote filesystem many reach for.

NFS is more annoying on Linux than just using Samba though, at least for the NAS use case. With Samba on my server I can just browse to it in KDE's file manager Dolphin, and samba configuration is a relatively straight forward ini style file on the server. A pair of ports also need to be opened in the host firewall. Contrast that with NFS, which last I looked needed several config files, matching account IDs between…

NetApp has NFS support and is widely used.

Re: Bugs Rust won't catch

#354

Earlier quoted context omitted.

Coreutils are not only used in interactive contexts. They are the primitives that make up the countless shell scripts which glue systems together. Any edge case will be encountered and the resulting poor performance will impact somebody, somewhere. Here's a related example of what happens when you change a shell primitive's behavior - even interactively. Back in the 2000s, Linux distributions started adding color out…

In short, NFS has a terrible data model and only pretends to be a file system.

No, any remote system would have the same problem if one expected to use it as if it were local.

Re: Bugs Rust won't catch

#355

Earlier quoted context omitted.

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

New things can be made optional and tested outside production, and should not be rolled out in an LTS edition.

Re: Bugs Rust won't catch

#356
post #328

> The Python one-liner is there because most modern shells refuse to create a non-UTF-8 filename for you. Both `echo -ne 'weird\xffname\0' > list0` and `printf 'weird\xffname\0' > list0` seem to work fine for me on Linux. Is this macOS-specific?

> Both `echo -ne 'weird\xffname\0' > list0` and `printf 'weird\xffname\0' > list0` seem to work fine for me on Linux. Is this macOS-specific?

Neither of those create a non-UTF-8 filename. (Both files are named "list0", which is valid UTF-8.) They have non-UTF-8 content, but that's not weird.

But it's not too hard to get a non-UTF-8 filename:

  touch $'\xff'
Both zsh & bash support that syntax.

(You could also use process substitution with printf, but that's more steps than necessary. So, something closer to your example would be,

  touch "$(printf '\xff')"
You can't put a \0 in the filename, as there's no way to pass that string in C.)

Re: Bugs Rust won't catch

#357
post #157

Earlier quoted context omitted.

How does CI catch logic bugs?

That depends on what tests you are running. In any significant projects you need a test suite so large that you wouldn't run all the tests before pushing to CI - instead you are the targeted tests that test the area of code you changed, but there are more "integration tests" that go through you code and thus could break, but you don't actually run. You can also run some static analysis that is too long to run locally…

That's true in general. In this case where the logic bugs are from not understanding the API being implemented (and in any similar case), tests wouldn't catch the bugs either (even integration tests) because good tests require understanding the contract of the unit being tested.

Re: Bugs Rust won't catch

#358

Earlier quoted context omitted.

Those Rust fans exist on almost all Internet forums that I have seen, including on HN. I do not care about what they say, so I have not made a list with links to what they have posted. But even only on HN, I certainly have seen much more than one hundred of such postings, more likely at least several hundreds, even on threads that did not have any close relationship with Rust, so there was no reason to discuss Rust.…

Could you find one such person on this thread? Someone making ridiculous claims about what Rust offers. I’ll tell you what I think you’ve seen - there are hundreds of threads where you’ve seen people claim they’ve seen this everywhere. That gives you the impression that it is universal.

This one probably covers it:

https://news.ycombinator.com/item?id=45921143

Re: Bugs Rust won't catch

#360

Earlier quoted context omitted.

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

These things were caught and basically all of them weren't covered by any test suite (not even GNU coreutils'). It's a bit bold to claim that it's actively worsening it when it's not an LTS.

> It's a bit bold to claim that it's actively worsening it when it's not an LTS.

It is LTS now. And not LTS releases are releases.

Post reply on HN