Hacker News Reader

Comment by RaleyField | Hacker News Reader

> We decided that it is unfair to _our sponsors_ that the above mentioned unlawful players can get away with their activity.

How is that unfair to them specifically? The purpose of this is to protect them by raising a paywall for anyone that isn't their 'sponsor'? (tangentially, that's why I prefer BSD/MIT, because people aren't as obsessed with other people doing dirty, nasty things with their free code.)

It's bad enough that these patches aren't integrated into the kernel like they ought to be or that they aren't included into mainline distros and are only ever present on custom built machines, now they are behind paywall as well. Damit, I don't want to move to OpenBSD.

View on HN

I think he means that it is unfair because the abusive companies are releasing an insecure and untested version of grsecurity, while using the grsecurity brand name in their advertising. This means that any vulnerabilities discovered will hurt the grsecurity brand, making customers trust it less, and hurting the actual legit sponsors using a real secure version of grsecurity.

It is similar to how any knock-off of a brand could hurt the brand; a crappier version of something that people will now associate with the real brand.

Grsecurity has been here for a while and I don't think common people know of it at all, they hardly know of what Linux is and half of them run it on their phones. Those who know of it will also understand that running outdated versions on outdated kernels isn't a fault of Grsecurity. Grsecurity isn't really a brand or needs to be defended.

That defence of the "meaning" of the trademark is not up to you to decide, that's for the owners of Grsecurity.

Similarly, Google presents its derivative work as Android, and it exercises its rights vigorously to defend the perception of its marque.

> not up to you to decide

Obviously, I'm just pointing out the fact that there are different groups of users for both products and one group isn't likely to be influenced by how others use the trademarked goods. Android has common people for its clientele, Grsecurity has security professionals that will judge it based on its intrinsic merit and not on what some subsidiary of Intel once did with it. Grsecurity de facto doesn't need to be defended, even if de jure they are entitled to the protection. That's why this is nothing but a money grab, what bothers me though is that they try to package it into something that it is not.

> Damit, I don't want to move to OpenBSD.

Why not? OpenBSD's awesome.

Maybe for servers. It's completely unusable due to performance problems on my i7-powered thinkpad.

"The test series, unfit in our view for production use, will however continue to be available to the public to avoid impact to the Gentoo Hardened and Arch Linux communities."

Why would you have to migrate to OpenBSD? Is the test series unstable?

Well, it's not called "stable".

One risk of using OpenBSD is a lot, but not quite enough, people use it on enough on random hardware and give actionable feedback to make it battle-tested, "Just Work" (TM).

Really? I run it on a PowerBook G4, and while it's sluggish, it's not entirely "unsuable". If a 10-year-old single-core machine can handle OpenBSD, I'd be amazed by even the slightest performance issue on a quad-core, hyperthreaded, modern PC. What's additionally surprising is that this is the case on a Thinkpad, of all things; IIRC, the OpenBSD devs dogfood OpenBSD pretty heavily on Thinkpads due to their FOSS-friendliness.

Does your laptop have an Nvidia GPU, by chance? In my experience, those do tend to have very bad performance on OpenBSD. Intel and AMD/ATI GPUs should work better.

Also, it's worth mentioning that OpenBSD's kernel has a whole slew of debugging and error checking features compiled in by default; compiling a custom kernel without such features can be done, but the docs don't really recommend it, since it becomes excruciatingly difficult to troubleshoot any problems with it.

My laptop has an Intel card, and everything is nominally supported.

You are free to be surprised all you wish: I went back to linux because I was sick of dealing with the system locking up for 5-10 seconds every time I opened, closed, or switched to a new browser tab. Couple that with 1-2 fewer hours' worth of battery life and I found myself very quickly asking what the point of "code correctness" was if the system just doesn't work.

A thoroughly frustrating experience from top to bottom.

Just saying. If you haven't already, I'd definitely send them a bug report and dmesg; that all seems very abnormal.

Because they feel bipolar on security sometimes. On one hand they go to the extremes with auditing and being early adopters of various security technologies but on the other hand they lack in other areas. Until recently they didn't sign binaries because the blessed method was to acquire patches via CVS which were signed. Iso files and their signatures are distributed via http because the blessed method of acquiring the signing key is to acquire and verify it over multiple networks, because PKI can't be trusted even though some of us check that https isn't being signed by a weird CA and companies like Verisign aren't likely to burn their CA business for anyone - so I'm forced to use Tor just to download an iso file complete with updating virtual machines hooked to Tor because who knows which exploits are being pushed from exit nodes... Then there is limited choice of packages and for everything else you are left to community ports and I don't trust randomers maintaining them. In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them, but it isn't prepackaged solution like Ubuntu is.

So true.

We would consider OpenBSD if it ran on AWS and stably supported ZFS. (We use FreeBSD with PF and ZFS.)

"NIH syndrome" resulted in signify rather than using normal, proven tools like GPG which Debian-base distros use for package management.

> We would consider OpenBSD if it ran on AWS

It probably could if Amazon wanted to support it. It does already run on Xen (which is what AWS is built on, IIRC).

> "NIH syndrome" resulted in signify rather than using normal, proven tools like GPG

Whoa there, pardner! Let's not be so quick to label every attempt at improving the selection of software in a given category as "NIH syndrome", eh? By that logic, "NIH syndrome" resulted in GnuPG rather than using normal, proven tools like the original PGP :)

GnuPG is great. Don't get me wrong. I use it all the time, even on OpenBSD. GnuPG is also a big program. It has a lot of features, and tends to be very complex. In the context of package signing, most of those features - like encryption, webs of trust, all that jazz - are way overkill; the OpenBSD folks just needed a tool that can apply a digital signature and verify that signature, and signify does that job pretty darn well.

There's also the fact that GnuPG is GPL-licensed, and OpenBSD has a pretty strict policy against including copyleft software. The implications of copyleft might not be important to you or me or the dog next door, but they're very important for the OpenBSD folks.

Re: ISO file signatures: the actual "blessed method" involving getting install media is actually to order a CD-ROM set. IIRC, the ISOs don't actually include the SHA256.sig file necessary to verify the installation tarballs; this is only present on the official CD-ROMs.

Re: package signing: yes, this was a strange oversight, and I'm glad they sign their packages now.

> Then there is limited choice of packages

It's not that limited, at least on i386 and AMD64 (other platforms are a bit more limited). Are there particular packages that are missing that you'd prefer to be available?

> and I don't trust randomers maintaining them.

So compile them yourself, with or without ports. OpenBSD ships with GCC, binutils, etc. Besides, I'm pretty sure this is the same situation as with Gentoo, Arch, etc. (and know for a fact that it's the same situation as Slackware's SlackBuilds.org).

> In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them

I run multiple OpenBSD servers. I can personally attest that the effort required to maintain them is minimal.

The only situation where OpenBSD maintenance is less than dead simple is when it comes to upgrading a machine where you don't have console access (such as a server in a remote datacenter), since now you have to do the installer's job yourself. When you do have console access, however, OpenBSD's installer makes it dead-simple to upgrade. Plus, it does so safely; no more total breakages like you'd get in, say, Ubuntu.

I will say, however, that it would be very nice to be able to track the stable branch without having to pretty much build OpenBSD from source. I think there are some folks that maintain stable-following ISOs, but this is really something that could and should be supported as a first-party feature.

> but it isn't prepackaged solution like Ubuntu is.

I'm pretty sure Ubuntu uses AppArmor - not grsecurity - so I'm not really sure how that's relevant in this particular discussion. Unless, of course, you happen to install grsecurity on Ubuntu, at which point I highly doubt OpenBSD not being an Ubuntu-like "prepackaged solution" is really as much of a problem as you make it out to be :)

Regardless, OpenBSD has as of late been progressing toward such a prepackaged solution. Boot the CD-ROM, mash the Enter key a few times (interrupted by entering some usernames and passwords), and you have a complete server operating system ready-to-go; a webserver or mailserver or fileserver or DNS server or timeserver or what have you is just an edit of /etc/rc.conf.local away. Maybe not a prepackaged desktop solution, there are plenty of other operating systems for that.

With that said, I'm not sure if the OpenBSD folks want to be comparable to Ubuntu. Canonical's demonstrated a willingness to compromise security and privacy for the sake of convenience (see: shopping lens), that's (hopefully) not something de Raadt and friends would want to emulate.

> companies like Verisign aren't likely to burn their CA business for anyone

Not voluntarily. You're inherently trusting some random company to be up to snuff on their security.

Re: ISO file signatures: the actual "blessed method" involving getting install media is actually to order a CD-ROM set. IIRC, the ISOs don't actually include the SHA256.sig file necessary to verify the installation tarballs; this is only present on the official CD-ROMs.

Because the CD-ROMs can't be intercepted and replaced, right?

I never said it was a smart philosophy :)

That said, it's arguably easier to intercept and replace a CD-ROM traveling on the Internet than to intercept and replace a CD-ROM traveling in a padded envelope between the UK and wherever you're having it shipped to (though various entities - like U.S. customs - could do so trivially, other entities would have to go through the extra trouble of bribing customs - not impossible, but it's a barrier to entry for quite a few potential attackers). Such an interception also requires good timing, lest you be sitting around somewhere for a few days waiting for the package to arrive at the particular point in the shipping route you're waiting at.

Plus, if I remember right, the physical OpenBSD media is done using a proper CD press. While plenty of people could conceivably access such a press, that's yet another step an attacker would need to take to create a convincing forgery.

Really, though, this just highlights why software distribution is such a difficult thing to pull of securely. The ideal solution would be to drive to Calgary and pay Theo de Raadt to burn you a CD-ROM, but I'm not sure how receptive he is to houseguests :)

> Are there particular packages that are missing that you'd prefer to be available?

octave, mono, etc. The whole reason openports.se exists. It's more an outcome of how small openbsd team is so it's not intrinsically their fault, but nonetheless is something that prevents wider adoption.

> So compile them yourself, with or without ports.

And track upstream for security issues and possibly apply patches to make it work on OpenBSD and whatnot which can easily turn into 30 minute dance each day just to maintain the system. It's fine on a servers where you are paid to administer it, but it's not fine on workstation dekstops.

> the actual "blessed method" involving getting install media is actually to order a CD-ROM set

What glandium said + it's rather anachronistic to expect operating systems to arrive by mail in the age of computers.

> so I'm not really sure how that's relevant in this particular discussion.

Ubuntu has its own (numerous) flaws, but it requires less work to maintain. It was more a remark that if grsecurity becomes unavailable on servers then even if you don't run it on desktop we should start thinking about moving to other platforms out of the principle that if the system can't be hardened then it shouldn't be used.

> octave, mono,

Both of these are available as OpenBSD packages (as evidenced by running "pkg_info octave" or "pkg_info mono", assuming you have a $PKG_PATH set). No openports.se required! :)

Reply on news.ycombinator.com