GPG Signing Tool using Azure Key Vault
- Dominant language
- C#
- Stars
- 729
- Forks
- 397
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 149
Description
Title updated recently to reflect the new status. Arcade support signing JARs, but we want to support producing GPG signatures using Azure Key Vault Keys.
-----
ASP.NET Core SignalR is shipping a Java Client in 2.2, which means the signing process needs to be able to process Java artifacts. There are two parts to this:
1. Signing the JAR files themselves - ESRP already supports this. @natemcmaster and I believe this will work with the existing signing tool. We just need to specify the correct certificate when we invoke it.
2. Producing Maven package signatures - The Maven Central repository requires that all packages include a GPG signature as a separate `.asc` file alongside them. Ideally, this is something the signing tool can do. For this we would need the signtool to be able to take a path to a GPG key file, and then use that key file to produce a signature file. Any file should be eligible for GPG signing. However, if the file is also being ESRP-signed, the GPG signature must be generated **over the ESRP-signed asset**. We've been provided guidance that we can manage the GPG key/signature ourselves as the JAR files are also signed by the ESRP tools.
Maven packages consist of four files:
1. A `.pom` file, which is an XML manifest (like a NuSpec). This file needs to be GPG-signed but **not** ESRP-signed
2. 3 `.jar` files (the binaries, the sources for debugging, and the JavaDoc documentation). Each file needs to be **both** GPG- and ESRP-signed
I think the approach here would be to enable a GPG key to be provided for an asset. If one is provided, the asset is signed **after** ESRP signing (if any is done). Also, ESRP signing would be made optional, so an asset can be signed with just the GPG key (to handle the case of the `.pom` file that doesn't require ESRP signing). I'm also thinking that the tool should support pulling the signing key out of Azure Key Vault.
I'm currently exploring the existing tool and am going to play around with sketching out a change in a PR, but I wanted to describe the scenario here in an issue before going too far down a path that doesn't align with other plans :).
Timeline: We're shipping the Java Client as part of 2.2. For preview 1 we're planning to manually sign the binaries, but we'd like to look at integrating this into our automation for preview 2.
Contributor guide
Assessment
This issue has not been assessed yet.