Sign new releases with a GPG master signing key. about os HOT 13 OPEN

Moving to the "os" repo since this is an OS build system issue

from os.

TL;DR - The short version of this is that GPG keys don't protect against hacked sites unless everyone knows there should be one, and checks for it. Since most people don't check them, they just don't help cover that eventuality. We have several other systems that do.

They are a good security improvement, just not protecting against website hacks.

Okay, so I'm going to start with a brief introduction. My name is Lewis Goddard, I work on elementary's website, notably as the lead on download delivery. I also work with eustasy, and contractually work with other distribution teams.

elementary run their system on five (previously six) distributed servers on Digital Ocean that we discussed when we left SourceForge, although they are technically hosted by eustasy for the reason of unlimited bandwidth.

The Linux Mint hack happened close enough to this deployment that it was queried at the time. I don't have access to the chat logs but the general response from within elementary OS to the standard of my security was "damn, dude."

A guide to hacking elementary OS distribution system

and substituting in your own malware-ridden files

So, let's say you want to distribute a dodgy copy of elementary OS. If you break into the website, to the point where you can modify it's contents, you can simply change the link and remove all references to hashing. You could also remove any references to a GPG signing key, but we'll ignore that minor detail for now. First, you must break in to a server.

There are two systems you can compromise to accomplish your task. Either the automatically deployed front-end, or the delivery network. Either way, you'll have to break through a rate-limited, key-only login with dual-factor for root privileges with usernames you don't know, on a server hidden behind CloudFlare.

Mint was hacked by another known remote-execution vulnerability in an outdated WordPress installation, something we don't use, and another known remote-execution vulnerability in their torrent tracker script, that had been out of support for nearly five years at the time. The way to avoid both of these is to:

1. Update everything.
2. Don't upload files in a publicly-accessible way.

Assuming you get in fine, on the front-end you have to know how to disable the auto-deployment, so your changes aren't eradicated the next time we change something. A remote-run script checks that the hashes are still in the docs, so don't even think about removing them.

On the delivery network, things are a little more complex. There's two important systems in place on the delivery network servers. That same remote-run script that verifies the hashes of both the distribution files, index, and configs, and a transmission instance, which effectively does the same thing while also working as a seedbox. If you delete or modify the files there, I get a notification and transmission simply overwrites with the correct file. If you turn transmission off, the script notifies me. If you move where Nginx points, transmission notifies me.

Basically don't mess with my servers, I will know.

A guide to hacking the entire internet

and doing whatever the hell you want because, hey, you own google now

If, as you say, someone where to both:

1. Redirect practically all elementary.io traffic to their location
2. Issue a certificate in the name of elementary.io

then you would effectively be able to do whatever you wanted, including just change basically every clock to say it was the 1st of January 1999.

The way to do this is surprisingly simple. As of the 25th of October 2016, the entire internet runs on 632 servers under 13 addresses. That doesn't seem like much, does it?

Basically compromising these servers would allow you to redirect all traffic wherever you wanted, within a few hours. Getting a certificate is easy with systems like Let's Encrypt, and you can then do whatever you want. There are a couple of upcoming standards against this, but nothing we currently deploy. But why would you, when instead you could:

1. Change the time on basically every computer, and probably most phones and radio clocks.
2. Make millions of PCs randomly wake up.
3. DDOS any website with the entire force of the internet at will.
4. Send millions of people to malware, or advert-ridden sites.
5. Not do any of those things, because you're not a bad person.

from os.

@lewisgoddard Thank you for putting this on the docket for 0.4.1.

For users unfamiliar with the concept, PGP signatures establish a logical property called cryptographic authenticity and cryptographic integrity. A PGP signature of a file proves that:

1. The file's integrity is valid; that the file is unchanged. This is provided by an underlying hash function like SHA-256, SHA-512, or one of the new SHA-3 functions.
2. The owner of the signing key has signed the file, implicitly meaning that they vouch for its authenticity. Only someone with the private key can create signatures. Typically this is accomplished by RSA or an ECC variant.

In a nutshell, if I know that a certain user, Bob, owns a specific key, and Bob has signed a message or file, I can take that to mean that Bob vouches for the authenticity and integrity of the file or message.

One problem remains: how do I know that this key belongs to Bob? This problem is called the key distribution problem and is a common problem across many different cryptosystems. There are varying solutions but for PGP, but two in particular are common now:

PGP's "Web of Trust"

This means that in this case, all elementary OS developers would sign the elementary signing key, giving the rest of us a way to verify the key. The problem of verifying the developers' identities still remains though.

Keybase

An increasingly popular solution is to use Keybase. Keybase allows users to host their public key and prove their ownership in a number of ways. For example, on my Keybase account, I have proved my identity by creating signatures and posting them on my websites such as Reddit, GitHub, Twitter, and even hosting proof in my DNS for my personal web page. This makes key distribution much easier; if I trust that the same person is using a given GitHub account, Twitter account, and owns the DNS records for a given domain (ie their blog), I can then much more easily verify their identity.

elementary OS would greatly benefit from Keybase, as it would make distributing this signing key much better.

Hopefully this has added some valuable information to the community at large!

from os.

Basically, in summary: this is a good thing to do (and we should do it!) but OP's original reasons aren't quite the right reasons to do it. But still good to do. :)

As an anecdote, OEMs like System76 will check GPG signing before imaging their machines; this is something @jderose and @djordan2 do for every update to the System76 Ubuntu image. Having the ability for people in the community to audit images improves the trust and integrity of the system as a whole.

from os.

I think a lot of people at elementary are already using Keybase, I know I am.

from os.

@codygarver

I know we've just released a new 0.4.1, so maybe now would be a good time to set up a company keybase maybe and share that around the council and sign this release. That way we can get documentation up and checked before we release something bigger like a 5.0

from os.

Apparently this is being worked on and GPG signing will be a part of a new build system.

from os.

@lewisgoddard Have you been able to integrate this into the new build system in the meantime? Or what else does it take to do this? Looks like this is the last issue in this milestone :)
Btw. Would be nice to have a guided way to verify my downloads like Qubes OS https://www.qubes-os.org/security/verifying-signatures/ or Tor https://support.torproject.org/tbb/how-to-verify-signature/ provide them.

from os.

"unassigned codygarver now"
How did this happen?
At least it was by accident.

from os.

@4jNsY6fCVqZv Cody left elementary, so he's being unassigned from any issues.

from os.

@cassidyjames "4jNsY6fCVqZv unassigned codygarver" -> sounds like I triggered it. That's why I want to ask curiously.

@danrabbit Moving it is certainly useful yes and it still fits into the website repository for me. Similar to Qubes or Tor, the website should include a guide for verification. What do you think?

from os.

I think your comment triggered GitHub to update the issue. That description is a little misleading is all. We the website doesn't really need an open issue for this until the OS build is completed for the first time.

from os.

Thank you for your explanation!
Will you then create a new issue for the website yourself or should I do so to keep things in mind?

from os.