Page MenuHomeSolus

Add OpenPGP/GPG key verification to package management
Closed, ResolvedPublic


This is a feature/security related task that pertains to Solus package management. I think it would be a good idea to verify downloaded packages via OpenPGP/GPG keys rather than hashes. Hashes (such as SHA-1 or SHA-256) can be manipulated to correspond to a malicious package if the Solus repositories are compromised. On the other hand, if the Solus repositories were compromised, but packages were signed with an OpenPGP/GPG key, pushing out malicious packages would be much more difficult. For an attacker to break PGP key verification, they would have to steal the private key and sign the malicious packages with it. So if the developer's public PGP keys were included with the base system, downloaded packages could be verified and installed more securely than if hashes were used.
Thanks for taking the time to look at this task!!

Related Objects

Event Timeline

DataDrake triaged this task as Normal priority.Dec 25 2016, 12:12 AM
DataDrake edited projects, added Plumbing; removed Restricted Project.
DataDrake added a subscriber: testmonkey.
DataDrake added a subscriber: DataDrake.

To be clear: the problem is not that we use hashes to verify packages, it's that we don't sign the package index (which contains the hashes) to prevent those hashes from changing.

Thanks DataDrake. I vote to increase the priority of this task.

@testmonkey This isn't a democracy. We will address this in due time.

ikey added a subscriber: ikey.EditedJan 22 2017, 10:20 PM

Also note we only serve over SSL. And that we hash both files and .eopkgs.
Secondly the problem of signing is nullified, because:

  1. Need to then force gnupg and the key into all Solus installations. And still somehow sign the repo at the same time while people get that update.
  2. This would require having the server automatically sign the index. And the problem here of course is that the private key would then be on the

server. So the argument about compromise makes no sense, because they'd still have the GPG key.

If you can solve that problem, then I'm all for it.

@ikey I believe that GnuPG is already installed on Solus by default. For the public key part, I think each of the core members that have upload access to the repository should have their public key in a keyring package that could be introduced via an eopkg dependency. As for signing the repository, I think there are two options. The first being have the server sign the packages with a core member's public key and delete the key afterwards. The second option is to sign all of the packages locally and then upload them (This would take some time, obviously). As for signing the index file, couldn't a core member sign it locally and then upload it to the server when a package is added or modified?

Infrastructure doesn't work like that. Nobody has upload permissions. The build server automatically takes the jobs from the queue (Which is protected by public key authentication), and then the build server, using its own keypair to communicate with the git server, pulls an immutable tag from the history, builds that. It then uploads using its key to the package server (isolated login with public key authentication only), which is then inserted into the unstable repository, where it is then indexed by the package daemon.

Manually uploading is entirely out of the question, look @ - I cannot be doing that every few minutes.

TL;DR *NOBODY* has rights to upload to (there is no mechanism) the repository. It's all protected by public key, with a build server that is literally in my front room.

i.e. this isnt Debian, nobody uploads packages. They are all built by a dedicated, isolated build server, and uploaded by that server from its own builds..

Hmm, didn't know it worked like that. It seems pretty secure now that I actually know how it works. I guess there is no need for OpenPGP verification like I was suggesting. So, just to be clear an attacker cannot queue a job as long as he doesn't have one of your guy's private keys? As for server to user, do you think SSL is enough to protect from Man-in-the-Middle attacks?

So basically the build queue system has to be public key based. It actually sits on a specialised account that does something like this in .ssh/authorized_keys:

command="/home/build/command ikey",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty $SSH_PUBLIC_KEY_HERE

Login is explicitly forbidden, its only access to the build register. Additionally, it's told which git repo + tag to build. So you would have to compromise the keys of an core members git & build ssh public keys, push to our git repos (which is publicly visible) and then it would still have to be built by my local machine and uploaded via a protected account, only to unstable.

I'm the only one with a direct (public key) login to the repo controller to actually sync back into stable at that point. So there are several layers which protect against this kind of attack. Recently we went even further with this, and replaced evobuild with the solbuild container build system (our own) to even explicitly disable networking in package builds, and force them to run as an unprivileged user.

I think at some point we should look to automatically sign our indexes, but we need to plan and test it so that nobody has to do some manual incantations to update their repos.

Understood. I think this Task can be closed.

ikey closed this task as Resolved.Jan 23 2017, 4:19 AM
ikey claimed this task.

Thanks. BTW I appreciate you bringing this up for discussion, and I think it's also good its here now for the sake of public ease of mind. Perhaps it would be beneficial if we documented these processes somewhere so that people know that internally, we're quite serious about these bits :)

Also if you have other things in mind to help us secure the *deployed* Solus further, I'm all ears!

Haha, no problem. Thanks for taking the time to discuss it with me. I also think it may be beneficial to document the process, I think that people should know how serious you guys are about security. :)

siru added a subscriber: siru.Jun 12 2017, 9:58 AM