> OpenBSD developers used to have development sprints and code check ins in Canada to work around US crypto laws.
Yip, I brought OpenBSD CD set back in that era (2.4 release!) and asked in the order if it included the crypto lib's and got a hand written note with shipment saying exactly why they ship from Canada and no worries. Believe it was Theo who wrote that as well. This was mid/late 90's era.
Maybe I should dig that out and pop into a museum of some sorts, as a bit of history and unique.
Excellent suggestion and added this to favourites as a backup reminder to do this. Hopefully be going thru that cupboard before the end of the year, so will get on that then. Thank you.
I do recall it was the initial release with blowfish so, that's pretty neat.
> It’s fun to see these posts but soo much backstory and history is glossed over and skipped.
> OpenBSD developers used to have development sprints and code check ins in Canada to work around US crypto laws.
That is mentioned in the article:
Fortunately for us, the project was always coordinated from Canada by undisputed project leader Theo de Raadt. There is anecdotal evidence that US-based developers would trek across the border for hackathons with clean slate equipment to install OpenBSD while in Canada and hack — that is, work on the system — and would then legally bring the result back with them.
> poorly written software will crash a lot more often on OpenBSD than elsewhere
The above quote is what sold me on OpenBSD as a Devl Platform. I work with AIX and decided to test the objects I wrote for an interface to a proprietary application. Testing them on OpenBSD identified memory leaks and things like that in 2 of them. So now I always test on OpenBSD when I am able to.
To do that on Linux would have required 1 or 2 third party applications I know nothing about, so I took the easy route :)
You’re not alone—this is somewhat common. Many programs that are written for multiple platforms benefit from this and I frequently see commit logs noting something similar to “Fixed a few <insert bugs, off by ones, memory allocation issue and whatnot here> that resulted in a crash on OpenBSD.” While great for the program and developer, unfortunately this also has the opposite effect of some less enlightened users reporting that some (poorly written) programs “always crash on OpenBSD.”
unfortunately this also has the opposite effect of some less enlightened users reporting that some (poorly written) programs “always crash on OpenBSD.”
IDK, given their stance on who it's for, i.e. "we write OpenBSD for us, use it or don't, we don't care", that seems like a feature not a bug.
It comes across as harsh or elitist to some people but the developers literally have no desire to gain market share, help newbies get started or port popular software to OpenBSD, unless they think it will directly benefit them.
I find it kind of fun and refreshing having to solve an issue I'm having with OpenBSD by reaching for the very fine manual and experimenting with it. You won't find dozens of sites by searching the internet, often with conflicting information, that try to explain what's happening to you and how you can fix it.
I have no option to use it at work right now but at home I always have one (old, recycled) server and one laptop running OpenBSD. And they're my favorite machines to use.
OpenBSD and Debian are really the only systems I use and trust today. I'm sure there are some other 'old-school' open source operating systems out there that are just as useful. But these two have been great over the last 25 years.
One thing that is glossed over is how Linux won to OpenBSD. I remember back in the 90's, web hosting providers boasted they used OpenBSD instead of Linux for security.
This is not as important as one might think, as long as updates keep flowing in (which they do). For 'ports,' there is sbopkg which keeps the software that is not included in the OS install up to date. Then there is pkgs.org and pkgsrc.org. And in a rare case if I need the bleeding edge version of something and is not available as a package from anywhere I can always install it by hand - Slackware is highly tolerant towards software that does not come in the form of a package.
I like OpenBSD, but I wish all these OpenBSD articles stopped repeating the fake news that it invented W^X. Some of us were alive back then, and know that's not true.
It invented the name W^X (a name that's technically incorrect because it's possible to have read-only pages that are not executable). But grsecurity patches had had it on Linux for, I believe, years. I'd been running it for a long time in any case.
OpenBSD copied W^X, and copied it poorly. E.g. in the first version they said "this cannot be done on 32bit x86". That's funny, because grsec/pax patches did exactly that. OpenBSD eventually realized this, and copied that too.
It was first in a mainstream OS to do it, yes. But that's not "inventing it".
That said, OpenBSD is a nice system. It would not allow the wave of extreme instability that Linux has gotten lately in the form of systemd. OpenBSD folks would not accept init and other core services crashing regularly.
I just need a bit more hardware support, and I'll switch. I'm fixing some of the blockers preventing me from switching as we speak.
Biggest thing I'll miss from Linux is Wayland. I hope that comes to OpenBSD soon.
Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another.
Yes, PaX kernel patches were published in October 2000, 3 years before OpenBSD made an official release with W^X (OpenBSD 3.3, May 2003). But without extensive changes in user space to ensure that data and code were separated in object files, you ended up with alot of complexity, and that complexity ultimately turned out to make PaX significantly less effective: https://lwn.net/Articles/126986/ Indeed, that's always been the problem with grsecurity patches in general--poor system integration which they've often tried to overcome with sophisticated (arguably overly sophisticated) methods.
Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability, it just was never comprehensively employed by a major operating system because it required extensive changes not only to kernels but also, as it turns out, to userland.
> Publishing kernel patches is one thing; publishing an entire operating system distribution where everything runs properly out-of-the-box with those patches enabled by default is quite another.
That's exactly my point. That's why I find it so annoying that these articles say the wrong thing.
> Neither grsecurity nor OpenBSD "invented" PaX/W^X. They were using pre-existing hardware features designed precisely for this type of capability,
The first version of PaX predate the page table no-execute bit in x86 hardware, and I believe (eventually) W^X didn't require it either. So no it was not a matter of merely starting to use existing hardware capability.
That's why it even was an invention in the first place.
Everything got vastly easier once the page-level execute bit was launched in hardware.
At the time, when OpenBSD was asked "why aren't you looking at what PaX did?", and they answered that "we don't care what others in the industry are doing". Which is a strange way to think you can create the best security.
So Linux patches: 2000.
OpenBSD: 2003.
Windows: 2004.
(not saying OpenBSD didn't do it better, because they don't care about binary compatability, making it easier)
If OpenBSD had "invented" it, then how could microsoft possibly have launched it only one year later?
Again, I do credit OpenBSD for being the first OS to do these things by default on an OS. But that is, as you said, is "quite another [thing]" from inventing it.
PaX and W^X use segmentation on x86. x86 code segments were by design and definition non-writable--you couldn't write to any region in a code segment unless a writable data or stack segment overlapped the same region. This was a deliberate feature of the hardware that happened to go unused in favor of flat memory models in the most popular operating systems.
Reading the article, and hearing them bang on about code quality and security, this reminds me. Is there any good modern book on C development with today's best practices? I have K&R but I've been told that's very outdated.
K&R 2nd edition is ANSI C. It will run everywhere, but I think nowadays C99 is expected at least, along a book on BSD 4.4 and the infamous Advanced Programming in the Unix Environment.
But the K&R 2nd edition is ANSI C is perfect to begin with. 99% of what you see in the src will be enough to be understood with that background.
I never could "bond" with OpenBSD, despite being a supporter and even still possessed of some of the distribution CDs circa 2002. It always felt just a little out of reach for me.
Historical email archives from the NetBSD mailing list which show some of the early conversations around why Theo founded OpenBSD:
https://www.theos.com/deraadt/coremail.html
Wow, this entire thread has made me appreciate OpenBSD a lot more compared to FreeBSD/NetBSD. I'm interested to hear about part 2 when it comes out and what he has to say about macOS/Apple.
Just installed OpenBSD 7.0 on Raspberry Pi 3b+ for testing purposes. Latest version supports and work with all devices out of the box including WiFi. It required to install brcm firmware manually with pkg_add though. The rest was smooth.
UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run."[0]
> Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run.
This means: 1. You trust Microsoft (you delegate the trust of your data to Microsoft).
2. You trust that Microsoft certificate will not be revoked.
Sorry, for me, secure boot is when i have the keys. When someone else has them they also have my data.
You do not understand how secure boot works. As a developer, I pick my own keys to use for signing on my devices. I do not trust Microsoft, but that’s moot: they have nothing to do with my use of secure boot. Source: I an a senior embedded engineer that has implemented secure boot for paying customers, across multiple devices and processor architectures.
That said, I despise vendors that lock down their devices using secure boot. This is unquestionably hostile behavior toward consumers, as the protection from malware usually also prevents user modification.
I wish there was a way to force disclosure of this anti-feature, as I actively avoid buying products that do not allow me to load my own keys and images.
Microsoft doesn't have access to your hardware. How would they exfiltrate your data without also having your TPM? If a key is revoked then you... disable secure boot.
Why do you trust a closed down chip like TPM, why do you trust secure-boot when the only time it's verifying the kernel is at boot time? Why trust something like IntelME? Why trust something like a proprietary UEFI?
I don't trust anyone, especially boot drives that have been exposed to the internet. That's why I would like a system of trust between my hardware components until the OS takes over. Why do you trust your boot drive?
Because most of the industry does, and companies have little choice in the matter. That's the power (and the convenience) of a monopoly. For your small-scale setup at home you are free to do as you wish (you can even use a RaspberryPi or whatever, although in such cases you are dealing with at least partially closed-source hardware anyway).
Does this mean that I need to get the private key to Microsoft for them to sign? Can Microsoft then record my key and impersonate me?
Or can Microsoft sing an NSA backdored Linux so it appears that is "secure/genuine"?
If the answer is yes to one of those then for me seems fair that someone would say that "it is not secure book if I can't remove Microsoft)NSA keys) and put my own and confirm it worked)" , seems to be a push for sanity that failed , like how we failed and we have now DRM into the browser.
Not require. But without a requirement, vendors are making their own choices. Some have gone with one-time programmable fuses to store the keys. Once programmed, only images signed with that key can be used. Otherwise, the device is a brick. Those vendors deserve to burn in hell (in my opinion as an embedded engineer that has implemented secure boot on a variety of platforms).
MS has been slowly prepping Windows on ARM to be viable as "Enterprise" device and for that it needs owner-controlled Platform Keys (to comply with their own requirements for enterprise offerings)
If you don't mind me asking, how did you get into embedded development? I'm trying to sample various types of development and see what I enjoy, and embedded development seems quite interesting to me though I've never done more than an arduino.
OpenBSD chooses to have an opinion on standards according to the project's own security criteria - simple inclusion/exclusion of a given technology X while ignoring their decision process is not a valid reason to critique the security posture of the project as a whole.
I fail to see how secure boot is worse than nothing. I don't need to even begin to think about supply chain attacks when the hardware in my house doesn't have trust between its components.
Read it again. I'm saying your concern of supply chain attacks on secure-boot and TPM are like worrying about the ash on your shirt while your house burns down. It's far easier to pwn a system with pre-boot injections on a system without signatures than one with them. Don't like where the signatures come from? Fine. That doesn't make the system have some mysterious backdoor or do whatever sensational magic someone told you it does.
UEFI is an abomination. Even putting aside removing user control the implementation is horrible and bloated. Just try building a bootable image for UEFI vs BIOS.
The title idea is very good but the implementation and the shady politics behind it are horrible. There's coreboot and libreboot. Hopefully either takes off or something else along the lines comes along.
I mean building a bootable image compatible with UEFI vs compatible with BIOS. Not building UEFI nor BIOS.
Like creating an "EFI System Partition" (FAT-based) or having a simple BIOS bootloader (usually with 2 stages, MBR + partition). With UEFI, it feels like you are booting an extra OS in between.
UEFI brings a lot of logic to the firmware. If you just want to boot one OS it's overkill, IMHO.
Oh you mean disk image; I was thinking ROM image. Yeah, it does seem to be very large and seemingly much of it unnecessary for booting. I wonder what led to that situation. It seems more like a replacement for the BIOS and DOS, not just the BIOS. I am surprised we don't see more people using it like that just for fun.
OpenBSD developers used to have development sprints and code check ins in Canada to work around US crypto laws.
It’s hard to explain how big a deal OpenSSH was/is and how much we owe to the OpenBSD project for it.
Also the fork from NetBSD is way more colorful.