7 days ago
@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