Custom signing keys for a linux feed and an API to swap them out?

[frei_zs]

Dear Support,

we are having our feeds for debian configured and they are running fine, but we are thinking about a possibility to be able to swap the automatically generated key.

In the admin settings we could not find a way to swap the key used for the repo and signing the packages to a custom one.

Does such an option exist?

Is there maybe an API to swap a signing key for a feed / repo, which can be used by CI/CD?

Many thanks!
Frank

[atripp]

Hi @frei_zs,

This is not supported; is there a reason that you'd want to do that?

My understanding is that signing keys are an outdated/vestigial concept that only makes sense if you're not using SSL/HTTPS.

Thanks,
Alana

[frei_zs]

Hey Alana,

thank you for the reply.

Our security team is asking to be able to revoke public keys and swap them out as a preventive action or in case of bad things that might happen.

While you are right, that SSL/HTTPS does secure the connection to a server, I haven't heard of signing repos is deprecated.

It ensures (besides the SSL/HTTPS) that the packages downloaded are eligible and verified for installation from the configured repo.

If this is not supported, then that's the way it is, although being able to upload a custom signing key would be a great feature. ;)

Have a great day,
Frank

[atripp]

Hi @frei_zs ,

I'm not really sure how signing keys work to be honest, but they seem to be really just used for the InRelease index?

Anyway, it was trivial to add a button to Delete the existing signing key. When you click that button, it will then show a page that allows you to Create a signing key:

So we'll get that in via PG-2807 in the next maintenance release (shipping on Friday).

As far as uploading a custom key, doing via API, etc., that's not trivial... but I'm thinking this will cover your bases. I can't imagine you are swapping these out often (or ever).

Thanks,
Alana

[frei_zs]

Hey Alana,

sorry for the late response!

And thank you for the update. You are totally right, this will not happen often, even rare, so I think we can work with this solution. :)

Have a great day,
Frank

[alex_6102]

Hi folks!

We are also interested in uploading and using our own signing key (which would be part of a chain from a CA).

Is there any update on the status of a feature in ProGet to support uploading and using custom signing keys?

Thanks!

cc @atripp

[stevedennis]

Hi @alex_6102 ,

Can you help us understand why one would want to use custom signing keys?

When a Debian repository (i.e. ProGet) is configured over HTTPS, signing the InRelease index is totally redundant and pointless. Moreover, from a security standpoint, these signing keys are cryptographically inferior to HTTPS.

The only reason to use signed indexes is so that apt doesn't issue a warning. They serve no other purpose in an HTTPS ecosystem.

On our end, it's a nontrivial effort so it seems like a waste of limited resources.

Thanks,
Steve

[alex_6102]

Hi @stevedennis !

This is not about transport security, that's fine over HTTPs. Using a custom signing key for the feed is an important security feature to ensure the feed itself is integral and authentic and the artefacts from the feed can be verified.

We run a CA and deploy certificates and keys signed from this central authority as part of a wider security measure across services, machines and users. Practically, this means that users install a single CA certificate which can automatically derive authenticity and validity across artefacts and services without having to manage multiple certificates since these are formed as part of a chain.

In the case of ProGet, we request the ability to upload a signing key (both through the UI and via API) and which would cryptographically sign the feed. Note that because a key can be uploaded, a public certificate for the key can be generated such that a user can then use either the CA or the feed's public certificate to verify the contents during package retrieval.

Another important feature of uploading a custom signing key is that we can issue and revoke keys, certificates and signatures (and with specific date ranges) from a centrally managed location without disrupting the service itself, issuing a notice if necessary. This would allow us to indicate if a feed and its artefacts were ever tampered with before upload or whilst hosted.

Thanks,

[stevedennis]

@alex_6102 thanks for the additional information! That makes sense - you are effectively looking for an external authority for content verification.

As far as I'm aware, Debian is the only packaging system that support this, although though NuGet has some limited concept of "signing" for author verification. We evaluated it and it simply doesn't make sense.

That being said, if you're willing to experiment with what we have in ProGet today, we might be able to make it work. It'll require a little database "hacking".

First, you'll need a new instance of ProGet without an encryption key set-up. That's the default configuration for a Docker image.

After creating a Debian feed, take a look in the Feeds table for the FeedConfiguration_Xml column. You will find a base-64 encoded property called FeedSigningKeyRing.

Here is how we generate that:

var bundle = new PgpKeyCollection { PgpKey.Generate(4096, $"{this.FeedName}@proget") };
this.FeedConfig.FeedSigningKeyRing = bundle.Encode();

Honestly I have no idea what that does or what format it's encoded as. This is a black box from the Org.BouncyCastle.Bcpg.OpenPgp library, and we just store the bytes as you can see.

Here is how we use those bytes:

context.Response.AppendHeader("Content-Disposition", $"attachment; filename=\"{feed.FeedName}.asc\"");

var keys = new PgpKeyCollection(feed.FeedConfig.FeedSigningKeyRing);
using var output = context.GetOutputStreamWithCompression();
keys.WritePublicKeys(output);

If you're able to "replace those bytes" with a format that works, then we can add a page that allows you to specify your own. If it's just UTF8-encoded ASCII, awesome. If not, we need some kind of instructions on how to replace those bytes too.

Otherwise, this is beyond our current understanding and would require us to (re-)learn how all this stuff works, test it, etc. Which is what makes it nontrivial.

Thanks,
Steve