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

221–230 of 395 posts

Re: Bugs Rust won't catch

#221

Post by foobar1274278 »

geocar wrote: post #202
sgt wrote: post #190

Earlier quoted context omitted.

"The alternative languages" - in this case you're talking about C, 99% of the time. So let's talk about that. Well written C code, especially for the purpose of writing and continuing to maintain mature GNU coreutils, is not a big risk in terms of CVE. Between having an inexperienced Rust developer and an extremely experienced C developer (who's been through all the motions), I'd say the latter is likely the safer op…

100% it's the safer option. The software with the best security track record of all time is written in C.

I'm curious which software you have in mind. Ex: seL4 is technically C, but I'd say the theorem prover is doing most of the real work there.

Re: Bugs Rust won't catch

#222

Post by kibwen »

goodpoint wrote: post #218
kibwen wrote: post #140

Earlier quoted context omitted.

As other people have mentioned, the goal of uutils was not "let's reduce bugs in coreutils by rewriting it in Rust", it was "it's 2013 and here's a pre-1.0 language that looks neat and claims to be a credible replacement for C, let's test that hypothesis by porting coreutils, giving us an excuse to learn and play with a new language in the process". It seems worth emphasizing that its creation was neither ideological…

> its creation was neither ideologically motivated nor part of some nefarious GPL-erasure scheme No, they openly refuse to accept any GPL code. And even have a strict policy of not even reading GPL code.

No, once you have an MIT-licensed codebase without a copyright assignment scheme, you no longer have the freedom to relicense it at will. You could attempt to have a mixed-license codebase, which is supported by the GPL, and specify that all new contributions must accept the GPL, but this is tantamount to an incompatible fork of the project from the perspective of any downstream users, and anyone who insists on contributing code under the GPL has the freedom to perform this fork themselves.

Re: Bugs Rust won't catch

#223

Post by yx827ha »

nh2 wrote: post #144
kibwen wrote: post #125

Earlier quoted context omitted.

They're not missing, Rust just ships them (including openat) as part of the first-party libc crate rather than exposing them directly from libstd. You'll find all the other libc syscalls there as well: https://docs.rs/libc/0.2.186/libc/ . I agree that Rust's stdlib could use some higher-level helper functions to help head off TOCTOU, but it's not as simple as just exposing `openat`, which, in addition to being platfo…

But those are all unsafe, taking raw strings. Why can I easily use "*at" functions from Python's stdlib, but not Rust's? They are much safer against path traversal and symlink attacks. Working safely with files should not require *const c_char. This should be fixed .

The nix crate provides the safe wrappers. https://docs.rs/nix/latest/nix/fcntl/fn.openat2.html

Re: Bugs Rust won't catch

#224

Post by adrian_b »

testdelacc1 wrote: post #133
adrian_b wrote: post #123

Earlier quoted context omitted.

"Rust" obviously does not promise that. On the other hand, there are too many less-experienced Rust fans who do claim that "Rust" promises this and that any project that does not use Rust is doomed and that any of the existing decades-old software projects should be rewritten in Rust to decrease the chances that they may have bugs. What is described in TFA is not surprising at all, because it is exactly what has been…

Where are these rust fans? Are they in the room with us right now? You’ve constructed a strawman with no basis in reality. You know what actual Rust fans sound like? They sound like Matthias Endler, who wrote the article we’re discussing. Matthias hosts a popular podcast Rust in Production where talks with people about sharp edges and difficulties they experienced using Rust. A true Rust advocate like him writes arti…

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.

Since the shameless promotion with false claims of Java by Sun, during the last years of the previous century, there has not been any other programming language affected by such a hype campaign.

I think that this is sad. Rust has introduced a few valid innovations and it is a decent programming language. Despite this, whenever someone starts mentioning Rust, my first reaction is to distrust whatever is said, until proven otherwise, because I have seen far too many ridiculous claims about Rust.

Re: Bugs Rust won't catch

#225

Post by ChrisSD »

kibwen wrote: post #205
jeroenhd wrote: post #178

Earlier quoted context omitted.

You have to choose something, and I'm glad they didn't go with the idiotic Go approach ("every path is a valid UTF-8 string" or we just garble the path at the standard library level"). You can usually abstract away platform weirdness at the implementation level, but programming on non-Unix environments it's more like programming against cygwin. A standard library for files and paths that lacks things like ACLs and lo…

As far as I can tell from Microsoft's documentation, WinAPI access for ACLs was added in Windows 10, which Rust 1.0 predates. And std::fs attempts to provide both minimalist and cross-platform APIs, which in practice means (for better or worse) it's the lowest common denominator between Windows and Unix, with the objective being that higher-level libraries can leverage it as a building block. From the documentation f…

> WinAPI access for ACLs was added in Windows 10

I'm not sure which docs you mean but that's not true. The NT kernel has used ACLs long before rust was invented. But it's indeed true that rust adds platform-specific methods based on demand. The trouble with ACLs is it means either creating a large API surface in the standard library to handle them or else presenting a simple interface but having to manage raw pointers (likely using a wrapper type but even then it can't be made totally safe).

> the de-facto standard winapi crate, which provides access to the raw syscall

Since the official Microsoft `windows-sys` crate was released many years ago, the winapi crate has been effectively unmaintained (it accepts security patches but that's it).

Re: Bugs Rust won't catch

#226

Post by masfuerte »

kibwen wrote: post #205
jeroenhd wrote: post #178

Earlier quoted context omitted.

You have to choose something, and I'm glad they didn't go with the idiotic Go approach ("every path is a valid UTF-8 string" or we just garble the path at the standard library level"). You can usually abstract away platform weirdness at the implementation level, but programming on non-Unix environments it's more like programming against cygwin. A standard library for files and paths that lacks things like ACLs and lo…

As far as I can tell from Microsoft's documentation, WinAPI access for ACLs was added in Windows 10, which Rust 1.0 predates. And std::fs attempts to provide both minimalist and cross-platform APIs, which in practice means (for better or worse) it's the lowest common denominator between Windows and Unix, with the objective being that higher-level libraries can leverage it as a building block. From the documentation f…

You misunderstand the documentation. Microsoft doesn't provide online documentation for versions of Windows that are no longer supported. Functions like SetFileSecurity have existed since Windows NT 3.1 back in 1993.

Re: Bugs Rust won't catch

#227

Post by kibwen »

gblargg wrote: post #81
slopinthebag wrote: post #14

Earlier quoted context omitted.

Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or vulns. I would have expected an order of magnitude more at least. Shows how good Rust is, that even inexperienced Unix devs can write stuff like this and make almost no mistakes.

Rewriting perfectly good code was a colossal mistake.

The irony here being that GNU's coreutils themselves originated as rewrites, from back when BSD's copyright status was still legally unclear.

Re: Bugs Rust won't catch

#228

Post by goodpoint »

kibwen wrote: post #222
goodpoint wrote: post #218

Earlier quoted context omitted.

> its creation was neither ideologically motivated nor part of some nefarious GPL-erasure scheme No, they openly refuse to accept any GPL code. And even have a strict policy of not even reading GPL code.

No, once you have an MIT-licensed codebase without a copyright assignment scheme, you no longer have the freedom to relicense it at will. You could attempt to have a mixed-license codebase, which is supported by the GPL, and specify that all new contributions must accept the GPL, but this is tantamount to an incompatible fork of the project from the perspective of any downstream users, and anyone who insists on contr…

This is simply false. You can accept GPL contributions and clearly indicate the names of the contributors as required by MIT. There is no "incompatible fork".

Re: Bugs Rust won't catch

#229

Post by kibwen »

goodpoint wrote: post #217
TheDong wrote: post #85

Earlier quoted context omitted.

It's based on an interpretation of "derived from". It does not matter if it's in the GPL explicitly or not since we're talking about uutils and their stance on it, and they've written that: https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f8609... > we cannot accept any changes based on the GNU source code [..]. It is however possible to look at other implementations under a BSD or MIT license like Apple's impl…

"we cannot accept any changes based on the GNU source code" is false. They are choosing not to accept it.

"We cannot accept it without issuing a breaking change to the project by significantly changing the license terms."

Re: Bugs Rust won't catch

#230

Post by duped »

concinds wrote: post #96
wahern wrote: post #2

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hash…

Reading that Canonical thread was jaw-dropping. Paraphrased: "Rust is more secure, security is our priority, therefore deploying this full-rewrite of core utils is an emergency. If things break that's fine, we'll fix it :)". I would not want to run any code on my machines made by people who think like this. And I'm pro-Rust. Rust is only "more secure" all else being equal . But all else is not equal. A rewrite necess…

This is a people problem and Canonical just isn't good at hiring people
Post reply on HN