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

Replacements for existing software written in Rust

github.com

Post reply on HN
Print view View original

141–150 of 229 posts

Re: Replacements for existing software written in Rust

#141

Post by clappski »

pdimitar wrote: post #100
hulitu wrote: post #79

Earlier quoted context omitted.

Is a memory-safe language a safe language ? Is it not possible to exploit rust ?

Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do. Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero. As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory sa…

> the chances for triggering a buffer underflow / overflow exploit are zero

Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero

[1] https://github.com/servo/rust-smallvec/issues/252

Re: Replacements for existing software written in Rust

#142

Post by laumars »

bluGill wrote: post #134
laumars wrote: post #77

Earlier quoted context omitted.

That’s not true at all. 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead. Also half the software mentioned in that gist should never be used in security-focused applications anyway (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already…

I use cat and awk in my build system. I can imagine bugs in either that I wouldn't notice in general that would compromise my application. They are off the wall enough that I don't think they have ever happened, but my application is an embedded system that has the ability to kill people so I'm a little paranoid. (not so much that I don't use awk in my build system where it is a useful tool)

My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. Rust won’t save you from a RCE bug because you’ve already granted them RCE from the beginning.

An overflow bug in awk is only exploitable if someone can craft input into awk. And if you’re allowing people to do that then you’ve already given them access to remotely run code without them needing a bug.

Re: Replacements for existing software written in Rust

#143

Post by geodel »

twa10 wrote: post #49
csomar wrote: post #39

I know people here are a bit touchy about Rust, and writing everything in Rust. But here is one advantage I have found with Rust programs: The installation just works. Cargo, as a package manager, is just wonderful. I have lost counts of how many times my "brew" or "pacman" failed to install something. It's much worse if it's Python; and things that work in macOS are not guaranteed to compile in Linux, and vice-versa…

Project specific centralized package repositories have the danger of being political (see npm and others). There already is a CoC here that can be used against wrongthink or people you don't like: https://crates.io/policies These days, I prefer Linux distributions or BSD ports, though Homebrew seems to be pretty casual as well.

I mean it is pretty simple. If one is not serving the cause of justice then they need to be brought to justice via social media.

Re: Replacements for existing software written in Rust

#144

Post by geodel »

senderista wrote: post #128

Would you like to replace a C program written by djb with a Rust program written by Uncle Bob?

Ah Uncle Bob,the philosopher of programing methodologies. I'd imagine writing any program beyond hello world with 100% test coverage would be beneath him.

Re: Replacements for existing software written in Rust

#145

Post by burntsushi »

clappski wrote: post #141
pdimitar wrote: post #100

Earlier quoted context omitted.

Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do. Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero. As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory sa…

> the chances for triggering a buffer underflow / overflow exploit are zero Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero [1] https://github.com/servo/rust-smallvec/issues/252

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of are zero."

But that is also absolutist. Instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler."

But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler or any dependencies or any other uses of 'unsafe' in your application."

And maybe that's still not quite it. So let's try again: "In safe Rust, the chances of are zero, modulo bugs in the compiler, any dependencies or any other uses of 'unsafe' in your application and any other platform specific tricks for arbitrarily rewriting memory used by your process."

That probably covers it. But it's a mouthful. It's probably best to avoid saying the chances of anything are zero. Instead, the key value add of Rust is that it flags areas of code that permit introduction of UB for easier auditing, and also enables building safe---for all inputs---abstractions for others to use. But humans are fallible, so there is and always will be an opportunity to fuck something up somewhere. What Rust gives you over something like C or C++ is a way to make assumptions that are more fine grained than, "I trust that every line of code written in the transitive dependency chain is free of UB."

Re: Replacements for existing software written in Rust

#146

Post by staticassertion »

de_keyboard wrote: post #5

Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.

If I know what it's written in I can infer a lot. If it's written in Python I know I don't want to call it in a loop, I have to care about my interpreter version if it isn't packaged with one, etc. If it's written in Rust I can infer that it'll start up quickly and likely perform well.

Re: Replacements for existing software written in Rust

#147

Post by cestith »

13415 wrote: post #22
faichai wrote: post #21

I might not be familiar enough with the original tools, nor the Rust ecosystem, so excuse me if this is misinformed. But the trend seems to be that the Rust tooling is a lot richer than their original counterparts. Is this accurate? And if so, is it super easy to write rich CLIs, with tabulated, coloured, interactive TUIs in Rust? Are their some common, widely used libraries driving this trend?

Nothing in Rust is super easy, it's an overengineered pile of crap and in 20 years from now people will be cursing at it daily.

If people are still cursing at your programming language 20 or 30 years later, you've done at least a decent job of things. Do you hear many people complaining about Eiffel, Dylan, or Boo lately?

Re: Replacements for existing software written in Rust

#148

Post by staticassertion »

rvz wrote: post #42
de_keyboard wrote: post #5

Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.

Agreed. I will put it even more directly. I could not care less about the hype squad screaming endlessly about every single side project that is written in Rust because of the sake of the language. If it is useful and it makes me money then fine, other than that I ignore it. If the tool that is being developed doesn't help me make money, then I do not care or I won't use it. As for choosing the best programming langu…

Why even go to a site like HN if your goal is purely to make money? You can make lots of money without reading 99% of the content here.

This is Hacker news. It's news for people who want to fuck around with tech.

Re: Replacements for existing software written in Rust

#149

Post by bdamm »

a-nikolaev wrote: post #106
benibela wrote: post #90

Earlier quoted context omitted.

I have been rewriting things in Pascal for years, because it is much safer than C, and no one cares about that :(

That's awesome though!

Somehow this feels like sarcasm, given that Pascal is older that pretty much everyone on this forum.

Re: Replacements for existing software written in Rust

#150

Post by kstrauser »

dlivingston wrote: post #105
Zhyl wrote: post #52

Wow, a lot of hate for this list, but I'll unpick something that is slightly below the surface here: We are currently seeing a bit of a command line renaissance. The justification for this is a 'rust rewrite', but as many have pointed out, just because something is in such-and-such a language doesn't make it good. However, what I tend to find with the new rust CLI tools is that they bring with them modern design sens…

My biggest problem with this list is that when I write shell scripts, I usually intend for them to be used by colleagues or others. Having non-POSIX applications used in these scripts means that portability is limited. Yes, I know that with aliases I can override this, but I’m not convinced yet that straying from “this will work on everyone’s machine” to “set an alias for X, and X will probably be an appropriate stan…

I see scripting and interacting as inherently different use cases. I absolutely love Fish shell for interactive use, but I don't use its scripting (other than to write functions I use from the command line) because it's not available everywhere. POSIX sh is much more appropriate for scripting, but I definitely wouldn't want to use it as my command line because it lacks all the greatness that Fish brings to the table.

Same with POSIX tools and their replacements: `find` is perfect when I know I'm going to run a script on a bunch of similar Linux hosts where I can't count on `fd` being available, but if fd is around I'm definitely going to use it at the shell prompt over find. As a side note, if you're doing cross-platform work, the new tools are better in some ways than the things they're replacing. Sure, `fd` isn't going to be installed by default on our out-of-the-box EC2 instances, but once it's installed at least it has the same arguments on Linux as on BSD and macOS. If I'm going to have to install GNU utils on a system to manage it, it's no extra work to install fd at the same time.

Post reply on HN