3

I'm following this tutorial to set up a debian repository

https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro

This repository will be managed by me and my colleagues. We want to sign the packages and the repo itself, so I need a GPG key. Naturally I shouldn't use my own GPG key, otherwise my colleagues can't manage the repo. So I thought of creating a new GPG key specifically for this repository, and then share the private key with my colleagues.

Is this the correct way to have a repo managed by many people? I don't like the idea of sharing a private key (and I think it wouldn't scale well for repos managed by many people), but on the other hand I don't see another way this can be done.

I guess there's a simple solution but my lack of experience on this sort of server is not helping.

Edit: sharing a private key was mentioned here http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/ (use case 2 at the very bottom)

1 Answers1

0

I haven't done this with Debian packages, but here's what we did with RPMs at a previous job: we made a signing server which holds the private key, and no one had access to it directly. (Well, except those of us who were sysadmins on that system; depending on your security needs you could make this "firewall" stronger.)

The signing server has a dropbox area. You can limit this by ssh keys or passwords or whatever, or, because of the next step, you can even leave it open to the world.

Monitor the dropbox area for new files. When they appear, check that they are signed with a valid key of one of the maintainers. If they aren't, delete them. Then, check if they are valid package files with whatever other checks you want, copy them to a staging area under a user account reserved for the signing service. After passing validation, the signing server resigns the packages with its own key (which, again, isn't directly readable).

And because it's convenient, we had the same server actually run the repository creation tools. Since, unlike with RPM, your repository itself is signed, this seems particularly convenient, because you can add that signing here, again with the private key that no one has direct access to.

A slightly stronger version of this removes the automatic pickup, and has the signers type the passphrase of the secret key every time. That way, the people maintaining the system might not even be able to sign packages by cheating and accessing it directly. (Of course, they could trojan the system, but let's leave that degree of paranoia for a different topic. Or you can just decide that you know you have to trust the sysadmins anyway and enforce this by policy, leaving the convenience of the drop-box approach in place.)

mattdm
  • 6,600
  • 1
  • 26
  • 48