OpenBSD Moving Towards Signed Packages — Based On D. J. Bernstein Crypto

ConstantineM writes "It's official: 'we are moving towards signed packages,' says Theo de Raadt on the misc@ mailing list. This is shortly after a new utility, signify, was committed into the base tree. The reason a new utility had to be written in the first place is that gnupg is too big to fit on the floppy discs, which are still a supported installation medium for OpenBSD. Signatures are based on the Ed25519 public-key signature system from D. J. Bernstein and co., and his public domain code once again appears in the base tree of OpenBSD, only a few weeks after some other DJB inventions made it into the nearby OpenSSH as well."

Comments

Very surprised that it took this long

[ModernGeek]

I'm surprised that this wasn't implemented a long time ago. Even Windows has had signed code for quiet some time.

Re:Very surprised that it took this long

[Anonymous Coward]

I'm just bothered that such a decision was made based off of the arbitrary capacity of a floppy diskette. The Floppy-based installer should compensate by having it fit across multiple disks and stored into RAM, or some other solution. What's next? Something won't run on a machine with less than 8MB of RAM, so it will be shoved off?

Re:Very surprised that it took this long

[Anonymous Coward]

OpenBSD is security by arrogance: nobody cares much to pay any attention to it, and anyone who comes with good intentions gets shouted down.

Distributing unsigned packages in 2014 shows such a lack of concern for even the most basic risks facing administrators and end users that I can only assume it was intentional.

Re:Very surprised that it took this long

[sumdumass]

Nah. the floppy discs work just fine. I remember getting them with cereal boxes in the mid to late 90s. You could do about anything other then fold them in half and they would still work for a while. After about 20 uses, you needed another though.

http://en.wikipedia.org/wiki/Chex_Quest

Here is an example. I think they were made of cardboard but some were made out of the plastic like what you would see on a floppy cutting board. Usually they were part of the box and you needed to cut them out in order to use them.

Re:Very surprised that it took this long

[fisted]

Wrong. Using binary package is just considered not the right way to do things, in OpenBSD land.
What you do is, check out the source repository, which does make sure the data you get hasn't been tampered with, then build it from source.
For mass deployments, you can then create binary packages from the result (secure distribution to other machines is your job, however. although that typically isn't much of a concern since it usually happens on the local network.

IOW, your comment is pure BS.

Re:Very surprised that it took this long

[cold fjord]

So, do you have a timeline for when other *BSD and Linux distributions switched to signed packages? It looks to me that FreeBSD only started that move at the end of October, and doesn't appear to be there yet. I don't think I would call that a "crushing" lead.

There wouldn't happen to be some trolling going on with your post, is there? Especially the "security by arrogance" bit?

Thu Oct 31 02:10:33 UTC 2013

Pkg 1.2 will be released in the coming month which will bring many
improvements including officially signed packages. FreeBSD 10's pkg
bootstrap now also supports signed pkg(8) installation.
 

Re:Very surprised that it took this long

[Anonymous Coward]

"Disc" is how English speakers outside the US spell the word describing a round, flat object. The reason one item is referred to as a "floppy disk" and one as a "compact disc" is simply their origin. The Compact Disc was developed by a Philips/Sony team, companies located in the Netherlands and Japan respectively. The floppy disk was developed by US based IBM.

Re:Very surprised that it took this long

[Sean]

And how exactly do you get the OS and compilers to build the source code with?

Re:Very surprised that it took this long

[Anonymous Coward]

Majority of Linux installations use RPM or APT, and those had GPG signing since ~2005.

Re:Very surprised that it took this long

[hairyfeet]

Well considering the fact that OpenBSD is in danger of shutting down due to lack of funding I really don't think starting this NOW is the greatest of ideas. Click on the comments to the article I linked to and they have a letter from de Raadt berating some for daring! to suggest that they might not ought to support a shitload of ancient formats like VAX if they are losing THAT much cash so I'd be amazed if they are here next year.

I'm sure I'll get hate from the *BSD fans but truth is truth and when you are bleeding cash like that you can NOT just give everyone a bad attitude and a "we deserve this", not when you are counting on those same people to support you. Either de Raadt stops running that huge mound of servers or they bleed to death, simple as that. And from the looks of that letter he'd be perfectly happy with it being the latter if it means giving an inch otherwise. Sorry guys but I've dealt with "never give an inch" types in business and in my exp they usually end up bankrupt. The wise owner rolls with the punches and accepts there is gonna be downturns, the arrogant owner says "I deserve it all" and runs the company into the ground.

Re:Very surprised that it took this long

[stderr_dk]

I fail to see why a BIOS would use the kernel of a general-purpose operating system.

Nevertheless that is what coreboot does. It used to be known as LinuxBIOS.

Re:Very surprised that it took this long

[allo]

disc = cd/dvd/...
disk = hard disk, floppy disk, ... (disc in a box, if you want so)

Re:Very surprised that it took this long

[Knuckx]

Coreboot doesn't use linux at all. Coreboot just initalises hardware, then loads a payload from ROM. That payload can be a Legacy BIOS service provider (SeaBIOS), an EFI environment (TianoCore), a bootloader (U-Boot, GRUB2), a Linux kernel, or pretty much any x86 code that does not require any BIOS/EFI services present.

Re:Very surprised that it took this long

[aliquis]

But they likely want to keep it being just ONE floppy.

Not bloat it like NetBSD which require TWO floppies.

(FreeBSD seem to be even worse! ..)

Re:Very surprised that it took this long

[Kjella]

Theo is the same that he's been for the last 20 years, on the one hand he's militant about the BSD license which gives away all the code to multi-billion corporations then a giant crybaby when the same corporations take the code and give him nothing but a cold shoulder in return. Oddly enough he's managed to gather a small following which barely keeps OpenBSD alive, usually by threatening to shut down OpenSSH development which is their only true success but this is neither the first nor the last time he's making such ultimatums.

If Linus is the benevolent dictator for life, Theo is the not-so-benevolent dictator for life. He started OpenBSD so he could run the show and any oppositition is harshly cut down. Don't argue with him about how the project's managed, what costs are necessary, everything is as Theo has decided it should be and he's only complaining that nobody is willing to fund his masterpiece. Your input is not wanted, just your wallet and he treats everyone from the smallest individual contributor to giant corporations the same. He's got balls of steel and an ego the size of a planet, but in the end he'll always be going around with a beggar's cup.

Re:Very surprised that it took this long

[TheRaven64]

What you do is, check out the source repository, which does make sure the data you get hasn't been tampered with, then build it from source.

Actually, it doesn't. OpenBSD is still using CVS for revision control. After the FreeBSD cluster compromise a couple of years ago, we found that the CVS repository was the one thing whose integrity we could not verify. The current FreeBSD CVS repository was created by exporting from subversion (which could be verified) and validating it against git (which also can be verified).

Oh, and OpenBSD does recommend getting the binary packages over using ports (but they don't release security fixes for binary packages, and don't support using a ports tree revision that doesn't match your base system revision), and they recommend getting binary packages with unencrypted, unauthenticated, FTP.

First thought upon seeing the headline:

[macraig]

What does openBSD have to do with tattooing your Johnson?

Re:First thought upon seeing the headline:

[Megahard]

That's why it has to fit on a floppy.

Floppy disks?

[thue]

Being limited by floppy disk support requirement sounds like a bad joke. Is that really relevant for any computer which is not hopelessly antiquated in 2014? For reference, Apple stopped shipping floppy disk drives by default in 1998.

Re:Floppy disks?

[Anonymous Coward]

And when you want to use a hopelessly antiquated computer for something, OpenBSD will be there for you.

Re:Floppy disks?

[gwolf]

No, it won't make much sense even with that in mind. Even less, in fact.

Embedded systems are usually factory-installed. In the factory, they don't do the installs via floppies. Most OpenBSD installs today are done off their (very good!) CD-ROM media, or maybe even more, by USB.

Floppy disks are used for a tiny percentage of installs (yes, even of *their* installs). Alright, they don't want to dump very old architectures that are known to work and have no other acceptable bood medium, but in the end... Basing the entire OS in the least common denominator takes a toll on the general usability of the system in everyday settings.

Re:Floppy disks?

[jawtheshark]

I gather that more serious OpenBSD admins simply boot from network and be done with it. (Google PXE, if you haven't got a clue what I'm talking about) I haven't used a USB or CD-Rom for ages to install mainstream Linuxes or OpenBSD.

Re:Floppy disks?

[Tom]

In a recent interview I can't find right now, Theo gave a perfectly good reason for this insane legacy support: OpenBSD is a volunteer project, and some of the most valuable contributors want this stuff to remain. Dumping the legacy systems would most likely mean losing those contributors. If they are important enough to the project, then the legacy support is the price it pays to keep them around.

Re:Floppy disks?

[TheRaven64]

None of these devices have floppy disks though. Compact Flash cards are a more common requirement, as they're basically IDE devices. I had one a few years ago with a custom firewall distribution that fitted onto a 32MB CF card, but a year later it was hard to buy a CF card smaller than 4GB and so I switched to a full OS install.

it won't fit?

[X0563511]

I call bullshit:
Copied right from /usr/bin:
"-rwxr-xr-x. 1 person staff 744K Nov 11 2010 gpg"

Packed with upx --best: (note this runtime unpacks, there is no loader library etc)
"-rwxr-xr-x. 1 person staff 327K Jan 19 05:40 gpg"

I should note this is a static binary.

Overly paranoid

[johnwbyrd]

I started using OpenBSD in 1998. It was a viable, timely competitor to Linux at the time, especially for building firewalls as such.

OpenBSD is a great example of what happens when you make life too difficult for end users and administrators in the name of Security. OpenBSD has never embraced the most recent release of anything -- if it's new, by definition it's insecure and it can't be trusted. Ergo, if you have to demonstrate the latest technology in whatever you're doing, you start with a Linux distribution.

From the article: "We wanted a tool that would fit on installation media, which meant minimizing code size and external dependencies." That's the breakage mode, in a nutshell. NO ONE in the world has been clamoring for an OpenBSD signing tool that runs on a floppy. But the designers are imagining the user requirements based on their own biases. This way lies the death of any commercial or open source software product.

Re:Overly paranoid

[johnwbyrd]

Okay, so what are you going to do about that paranoia? Use OpenBSD? That's too bad, because the NSA has already inserted cryptospy code into the distribution without Theo's knowledge. Oh, so you'll just compile it yourself from the sources, and read and review them all yourself? Too bad because your compiler has code in it that secretly inserts itself when it detects compilation of the OpenBSD kernel. Oh, but you're going to review all the compiler source code yourself and do a Canadian cross to build a clean compiler which you will then use to build a clean OpenBSD kernel from source? Too bad, because Bernstein has been paid gold in a secret numbered bank account in Thailand to insert a bug that will only manifest when it checks the installation of a new kernel on your machine.

Eventually, you have to put your tinfoil hat away and figure out how to get some work done on that there computer. Paranoia has a useful limit.

Re:Overly paranoid

[johnwbyrd]

When you can't run the software that your job requires on them.

Re:Overly paranoid

[Burz]

Run whatever software you need on Qubes. Even then your system is likely to be more secure than OpenBSD.

Floppy discs and the programmers who use them!

[danpbrowning]

Many members are up in arms over the large new utility: "Programmers these days with their fancy new computers and their gigantic 'five and a quarter' new-age magnetic spinning discs are constantly looking down on us 'old-fashioned' punch-card programmers. Why can't they write a new utility that supports six rows of 8-bit EBCDIC? Laziness. This just proves that OpenBSD don't care about small, home-built systems. Sixty four bytes is big enough for anybody."

Re:Dupe?

[abhi_beckert]

It's not a dupe, it's just that everyone installs from source on OpenBSD, so signing the binary never made much sense.

Debian has had it for a while

[Anonymous Coward]

I'm not as familiary with RedHat or SuSe archives, but I did a little digging over at debian.org.

The debian-archive-keyring package changelog shows an initial release on 10 January 2006, or eight years ago.

Digging deeper, the devscripts changelog shows the signchanges program (now called debsign) was added in July 1999. The changelog entry implies that it was to aid an already existing signing system, so Debian has had it for about 15 years, possibly longer.

Now consider that Debian has a reputation as a late adopter.

Probably for bootable CDs

[Animats]

This is probably because they want the signature checker to fit in the CD boot loader. For historical reasons, bootable CDs imitate a floppy during the initial boot process, and contain an image of a 1.44MB floppy with a FAT file system. When you boot an PC-type x86 machine from CD, that simulated floppy (the file "floppy54.fs" for OpenBSD) is read by the BIOS and a file from it is executed.

This process is so retro that the initial program loaded is executed in 16-bit X86 mode.

Re: Probably for bootable CDs

[buchanmilne]

But, if you are booting from CDs, and the CD has the rest of the media, why do you need the utility for verifying signatures on the boot media (1.44MB image)? Bootstrap the installation image from the iso9660 part of the CD (or network in the case if a network install)? and have that contain the signature verification utility.

Hint: RPM-baswd distro have been doing this since rpm 3.x, or about 1999.

Really, who uses floppies for installation these days? Sure, maybe floppy emulation on a DRAC or iLO or ILOM, but they all
-support CDROM or DVD emulation
-PXE boot (with relatively large images possible via TFTP)

If none of these are options, just write the whole (hybrid) ISO image to a 4GB USB flash disk and be done with it.

I personally haven't used an actual CD-RW or DVD to install a syatem in about 5 years. Either network install booted via PXE for servers, or USB flash disk for laptops.

Re:You're wrong.

[stderr_dk]

Also important is: which version are you looking at? The 1.4 series (still updated) is intended for smaller/embedded installs, while the 2.x series is intended for mainstream (especially desktop) usage

It's also important to ask why they are even looking at the main gpg executable and not gpgv?

gpgv is a stripped-down version of gnupg which is only able to check signatures. It is smaller than the full-blown gnupg and uses a different (and simpler) way to check that the public keys used to make the signature are trustworthy.