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

Re: Integrating "safe" languages into OpenBSD? (2017)

marc.info

Post reply on HN
Print view View original

221–230 of 400 posts

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#221

Post by AlphaSite »

adev_ wrote: post #182
staticassertion wrote: post #171

Earlier quoted context omitted.

You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.

> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for y…

I think there’s a difference between being able to use make and ending bale to understand make. My suspicion is that most people can’t understand the makefile for a project they didn’t write or spend significant time on.

It’s nice that their is a stable convention, but it’s a shame that it’s so dated and is missing so many modern conveniences (mostly to do with dependency handling).

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#222

Post by michaelcampbell »

cycloptic wrote: post #59
jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…

Somewhat academic as I have no dog in the fight, but ...

> To actually achieve POSIX-compliance is not an easy task and requires lots of testing.

Why are the existing tests not enough for a new implementation?

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#223

Post by staticassertion »

numbsafari wrote: post #209
staticassertion wrote: post #73

Earlier quoted context omitted.

> This is pretty much a judgment of Rust: I guess. It's really a judgment of Rust (specifically the compiler toolchain) for this one use case. > I would think that OpenBSD developers/users would care about security, Maybe. Again, I think "cat" and other system tools are really low on the list of priorities for anyone securing a system. Not to say that they don't represent attack surface, by any means, but there are j…

“cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy: https://www.cvedetails.com/cve/CVE-2014-9471/

There is a big difference between being having vulnerabilities and being valuable attack surface. Again, I am not saying that cat and others do not provide attack surface, or even valuable attack surface, only that step 1 is not "rewrite cat".

Generally "cat" is not exposed to the internet, and if you're running a service and you said "I'm concerned about local attackers using cat" it's probably a lot easier to just put the service into some sort of environment (container, sandbox, user, whatever) that doesn't give access to cat.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#224

Post by bluGill »

Arch-TK wrote: post #128
throwaway894345 wrote: post #72

Earlier quoted context omitted.

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

Python's build ecosystem IS sane and well-designed. It's the pinnacle of package handling so far. A separate package manager which works together with a separate build system which still works when a distribution wants to package a python package. What build systems like cargo seem to think is awesome is probably the most backwards idea of build systems I've ever seen. Static linking and automatic downloading of depe…

Python packages don't interact well with the built in package manager on my os. It doesn't even try to, which is a major design flaw.

Now if python had a way to do this and package managers refused to interopate (as I believe would happen) we would have a different discussion.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#226

Post by staticassertion »

cosmojg wrote: post #187
staticassertion wrote: post #150

Earlier quoted context omitted.

> You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? Yes, I think it is fair to say that I am very familiar with all of this information. I work in information security, and was quite into Linux kernel security for a while. I disagree with your assertion about it being the most secure general purpo…

> I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) Could you please go there? I'm very curious what the contenders for "most secure general purpose OS" might be.

I think geofft's points go a long way. I think having this conversation would require a lot though - what is "Secure" what is "general purpose". Is OpenBSD even general purpose? Is the base install general purpose? What makes an OS secure?

I think maybe as a "with 0 configuration to the OS/ services" OpenBSD could be a top contender. With "I have practical security challenges to solve and I'm willing to change things in this system" I might choose Linux. If I'm handing a laptop out to an employee or friend, maybe a Chromebook, or even Windows! It's a pretty nuanced discussion that I couldn't do justice to without really caring and feeling that everyone involved in the conversation is equally invested/ coming in with the right attitude, which is impossible on an internet forum.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#227

Post by staticassertion »

utborin wrote: post #188
staticassertion wrote: post #61

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

In a thread about OpenBSD, > Developers in particular don't generally care about security Thanks, now I have to clean a mouthful of coffee off my screen!

Is the joke that Theo said virtually the exact same thing in the linked thread?

Again, quoting Theo directly...

> However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 10 years for adoption, let people should switch languages? DELUSION.

Anyways, I think you've clearly misunderstood my point.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#229

Post by jacquesm »

ajross wrote: post #166
jerf wrote: post #140

Earlier quoted context omitted.

" There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet." IMHO, that's basically not possible, so it isn't a fair ask. If the Rust community produced a drop-in replacement that is every bit as good as readline in literally every way... still nobody would switch, because why would they? What's the benefit? You spend all th…

> IMHO, that's basically not possible, so it isn't a fair ask Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too. Rust didn't hit any o…

At a guess because it is much easier to yell from the sidelines than to be exposed with your stuff out in production across major installations. Maturity of code is measured in blood, bugs and overtime, regardless of what language it is written in.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#230

Post by busterarm »

bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

I'm not much for Rust, but I'm essentially a deploy/tooling engineer and supporting a build system for hundreds of engineers and tens-thousands of servers. I've worked in a few dozen languages at this point and have seen 20 years of the problems in this field.

I'm going to tell you that static linking is the only way to go.

The idea that needs to die is the personal workstation. It's just another deploy target. Ideally whatever is doing builds is reproducible and throwaway. Leaving those artifacts around on disk introduces its own host of problems.

Disk is cheap and you shouldn't have tons of binaries on your systems for no good reason.

(Aside from this though, I'm in full agreement with Theo.)

Post reply on HN