Private signing keys

depot

#1

Is there a way to reject previously private signing keys?

We finally have an on-prem builder and in the past we shared our keys around. Yes, I know never share your private..

A few scenarios I have seen that I want better protection around:

  1. User does not have access to the origin but is still able to create packages with the old private/public key.

  2. User does have access to the origin and creates packages with the old private/public key AND then is able to publish them in on-prem builder.


#2

As far as I know, there’s no way to reject origin signing keys. One idea would be to generate new keys for your origin and download them. Builder will only use the most recent private key, AFAIK, so that should do what you want.


#3

If I’m understanding, what you want is revocation: marking an old private key invalid. Is that right, @bdangit? Currently, I don’t think that’s part of our model since origins retain all their historical public keys. It sounds like to getting what you want would require re-signing old artifacts with the new keys, but even if we did that, it would require clients to check with builder before every package verification that the key used to sign it hasn’t been revoked.


#4

@baumanj I worry about the compromised accounts that do have access to the private key and permission to upload into Bldr.

They can build a package with my origin (with extra things) and upload them into Bldr. If others in the company depend on that package, they would be affected.

From a build perspective, if I can somehow mark that private key has been compromised which means no longer trust who signed this then they wouldn’t be affected.

From a runtime perspective, my hab-sups also won’t trust this and should not install the new package.

So yes, it would require the clients to check in with Bldr to say hey is this public key still okay. I believe right now, we have defaulted on try to get the public key from Bldr otherwise if you don’t have access you can also check the key cache for the public key.


#5

I think the concerns you identify are valid. It would require some changes to our model (and I also may be mistaken about some parts), so I think @salam would probably be the best person to take it from here.


#6

@bdangit adding signing key revocation is not currently on the immediate radar, but this seems like a reasonable and generally straightforward feature that could be added. Another related work item that is on the current work plan for H2 is to add better RBAC support for origins. So for instance, you could only have upload privileges given to certain members of the origin. That could help mitigate your scenario #2. If you want to open an issue for this in the builder repo, we should be able to get it on the backlog.


#7

Looks like you have a ticket for this: https://github.com/habitat-sh/builder/issues/835. So I added a comment of why this is important.