OpenBSD: How it all started
blog.apnic.net
blog.apnic.net
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.
Unfortunate since there is soo much drama and progress missed.
Does not help that the "part 1" is missing from the link either.
> 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.
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.
I do recall it was the initial release with blowfish so, that's pretty neat.
I was in college and ran Linux but my roommate ran NetBSD and was telling me all the mailing list drama.
It is still archived here under footnotes 11 and 12
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 :)
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.
Isn’t https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In.... the answer?
Linux was completely safe, BSDs were a risk, the choice was easy.
USL / AT&T basically kneecapped the bsds.
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.
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.
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.
https://en.wikipedia.org/wiki/Executable_space_protection#Pa...
https://pax.grsecurity.net/docs/pageexec.txt
contrasted with:
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.
"What is UEFI Secure Boot NOT?
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]
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.
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).
That's a pretty bad comparison in a time when every day 100's of "industry's" get ransomware'd.
>That's the power (and the convenience) of a monopoly.
No that's the week point and inconvenience of every brand monopoly.
Because HIDS with my own signed hash database and hids-exec.
But i cannot scan/proof what the UEFI TPM IntelME makes.
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.
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.
Because one of them requires ability of device owner to delete any pre-existing platform keys and load their own set.
On x86 based systems.
My understanding is that Arm systems require the opposite.
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.
(And I include ostensibly FLOSS in it as well, as shitty firmware can be worse than no firmware)
If you keep the default Microsoft keys a big YES.
Just trust secure-boot if you absolutely believe that there is no chance that there is a hidden "non detectable but updatable" key ;)
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.
Can you proof that in the first place?
That's going to be a hard no.
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.
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.