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

301–310 of 400 posts

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

#301

Post by riquito »

spion wrote: post #250
zozbot234 wrote: post #219

Earlier quoted context omitted.

> Want to have two pieces of software on one computer that rely on... idk, two different versions of libwebsockets? You've pointed this out yourself, but this works just fine in any sensible OS. You just have two or more versioned instances of libwebsockets in your /usr/lib directory, and a symlink (or multiple symlinks with different partial-semvers) that points to some appropriate default. I think even Windows is d…

Why does a "default" need to exist at all at the system level? Why not just have various versions available and have version decisions be local to the software being developed/used.

Security. By having defaults the operative system can share the most secure minor version of that library (or multiple major if necessary). When you have a copy of a library for each program then most of your programs will end up using obsolete or unsecure dependencies.

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

#302

Post by a1369209993 »

geofft wrote: post #157
hedora wrote: post #127

Earlier quoted context omitted.

> Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough. 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? I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.

I thought it was the most secure general purpose operating system because it's so rarely used - especially for use cases like running untrusted code in unprivileged accounts - that it's a low-value target. Sure, OpenBSD doesn't have exploitable security holes when used as e.g. a packet router, but when was the last time Linux did? OpenBSD's website says things like "Only two remote holes in the default install, in a…

> When was the last time you saw a remote hole in the default install of, say, Ubuntu desktop?

Literally right now, with snaps. If you only mean unintentional remote holes, and not deliberate backdoors, then we have very different ideas of what "most secure general purpose operating system" means.

Also, BSD doesn't generally actively refuse to fix security holes when thousands of people compain about them.

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

#303

Post by staticassertion »

numbsafari wrote: post #298
staticassertion wrote: post #223

Earlier quoted context omitted.

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…

> step 1 is not "rewrite cat" Totally agree on this point. In fact, I think it’s brash for the rust armada to think that the borrow checker alone is going to help replace 20+ years of maintenance on these kinds of tools, which often crufty, and gnarled by the sands and whims of generations that preceded us.

As a member of the Rust Armada I can tell you that I don't believe that rewriting cat in rust is something I consider a high priority.

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

#304

Post by creshal »

AzzieElbab wrote: post #13

I have been using bat and exa along with alacritty for a while. All of them are pretty good https://github.com/alacritty/alacritty https://github.com/sharkdp/bat https://github.com/ogham/exa

exa still just flat out crashes when supplied with a ctime pre 1970.

If that's supposed to be a poster child of how well rust tools work, I fully understand Theo's vitriol.

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

#305

Post by microcolonel »

Re: bootstrapping the toolchain from the base system; we have mrustc now, and it can build rustc. rustc uses LLVM for codegen, and LLVM is in the base system now.

So at least that bit is there.

What I think would be a good candidate for first base-system rust component, in case you are considering taking on a task like this, is a milter for OpenSMTPD.

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

#306

Post by geofft »

a1369209993 wrote: post #302
geofft wrote: post #157

Earlier quoted context omitted.

I thought it was the most secure general purpose operating system because it's so rarely used - especially for use cases like running untrusted code in unprivileged accounts - that it's a low-value target. Sure, OpenBSD doesn't have exploitable security holes when used as e.g. a packet router, but when was the last time Linux did? OpenBSD's website says things like "Only two remote holes in the default install, in a…

> When was the last time you saw a remote hole in the default install of, say, Ubuntu desktop? Literally right now, with snaps. If you only mean unintentional remote holes, and not deliberate backdoors, then we have very different ideas of what "most secure general purpose operating system" means. Also, BSD doesn't generally actively refuse to fix security holes when thousands of people compain about them.

Granting your framing for the sake of argument, then we've got one remote hole in a heck of a long time in Ubuntu desktop, and still nothing in macOS or Amazon Linux. I'm certainly not claiming that any of these OSes is better than OpenBSD. I'm claiming they're all about the same, and the "OpenBSD cares more about security than everyone else" narrative isn't actually based in evidence. OpenBSD has a particular view of security, which they care about very much, and OpenBSD has done some very cool and precedent-setting things - but that particular view is applicable to narrow use cases, and other people quite reasonably care about other parts, while incorporating versions of innovations from OpenBSD too.

Also, if I understand your unstated argument correctly, even if we don't admit a difference between unintentional remote holes and "deliberate backdoors," there's still a huge and meaningful difference between remote holes that can be exploited by a tiny number of people and remote holes that can be exploited by anyone.

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

#307

Post by creshal »

vvanders wrote: post #285

> As a response to this, Theo asked rhetorically "Where's ls, where's cat, where's grep, and ... For my money ripgrep knocks the socks off of grep. I can't recall if it's perfectly posix compliant but it's blazing fast and has a much nicer output.

From ripgrep's FAQ:

> Do you care about POSIX compatibility? If so, then you can't use ripgrep because it never was, isn't and never will be POSIX compatible.

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

#308

Post by adev_ »

DagAgren wrote: post #296
adev_ wrote: post #215

Earlier quoted context omitted.

> enjoy some arcane technical artifacts Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry. These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences. That is not 'gatekeeping', there is no gate to keep here. I name more that fight la…

Speaking as a C developer of twenty or thirty years or so who's used make for all that time: Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.

> Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.

Great. And you could be a developer for 40 years, if you do not precise why and how. This is your comment which is arcane bullshit and complete nonsense.

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

#309

Post by Arch-TK »

roblabla wrote: post #163
Arch-TK wrote: post #128

Earlier quoted context omitted.

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's build ecosystem IS sane and well-designed. It's the pinnacle of package handling so far. Big oof. Python packaging has a lot of problems, and defaulting to a single shared location when installing, that might conflict with your default package manager, is very high on the "What the fuck are you even doing" list of issues. You also very easily get into version hell. Unless you start using virtualenv, at whi…

> Python packaging has a lot of problems

Sure, but I think that what systems like cargo provide is worse across the board.

> defaulting to a single shared location when installing, that might conflict with your default package manager, is very high on the "What the fuck are you even doing" list of issues.

This is easily solved if pip was to have a way of listing all dependencies which it's about to install. Then I could mangle the names to fit my package manager's style and automatically install them with my package manager. But I will give it to you, this omission is one of the few things which pip could improve on.

> You also very easily get into version hell.

This is not a pip problem. Stop using things which result in dependency hell. Semver solved this problem a long time ago. If developers insist on not stabilising their APIs and breaking them all the time those developers libraries' shouldn't be used.

> Cargo has a lockfile to ensure the dependency downloaded is the exact same,

Great, now I can make my software depend on an out of date and vulnerable version of a library. Why do you think encouraging bad behaviour is a good thing? Yes, getting versions right is hard, but it's better than the alternative of static linking and having to update 100 pieces of software when you find a critical vulnerability in . This gets even worse when not only does every developer have to change this lockfile to update their code but now because they used lockfiles and as a result the upstream library developers felt it was safe to break API 100 times between when that library was locked and when it was patched. Now a simple update of which would involve pushing an ABI compatible patched version via distribution channels requires 100 developers to all push updates to their software which may or may not include having to re-write portions of their software.

> It defaults to the most convenient things for developers because packages will be worked on many more times than they are packaged.

Only because you allow and encourage it to happen. Which I hope I've made my point clear is NOT a good thing.

> So does python/pip. And most package managers I've worked with. Crates.io will refuse packages that have github dependencies though, so this only comes up when packaging something that isn't really ready to be packaged.

So it's good to see that this issue has been appropriately addressed. I wasn't aware that this was a restriction of crates.io. That being said, it doesn't stop everyone and their grandmother from just not using crates.io for certain things and not having their stuff on crates.io.

I wasn't aware this was possible with python but I also never see python packages using it.

> Rust currently has no stable ABI (apart from the C ABI).

Which isn't a good thing.

> 2. Generic functions and impls would not be part of this, as monomorphised variants would have to end up in the final binary. I believe C++ has the same problem with templates. A lot of Rust APIs are generic. This could theoretically be fixed (at least partially) through automatic promotion to dynamic dispatch, or other similar schemes.

I think Ada has a solution for this. Not 100% sure but it can't be impossible to solve if only rust developers made it their goal to make libraries work somehow.

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

#310

Post by ori_b »

spion wrote: post #250
zozbot234 wrote: post #219

Earlier quoted context omitted.

> Want to have two pieces of software on one computer that rely on... idk, two different versions of libwebsockets? You've pointed this out yourself, but this works just fine in any sensible OS. You just have two or more versioned instances of libwebsockets in your /usr/lib directory, and a symlink (or multiple symlinks with different partial-semvers) that points to some appropriate default. I think even Windows is d…

Why does a "default" need to exist at all at the system level? Why not just have various versions available and have version decisions be local to the software being developed/used.

It doesn't. Just don't install it if you don't want it.
Post reply on HN