Support NuGet package signing using Azure Artifact Signing on Linux

[Bradley Grainger (bgrainger)]

Disclaimer

I understand none of this code; it was produced entirely by GitHub Copilot using GPT-5.5.

The point of this PR is to demonstrate that with these changes, psign-tool could produce a correctly-signed NuGet package using Azure Artifact Signing under Linux (Ubuntu 24.04 on WSL2). I'm opening this PR in case having this information is helpful for producing a new version of psign that has this support built-in; I'm not expecting this to be merged as-is (although it's fine if you do).

I am interested in getting this scenario working, and am willing to produce more targeted fixes (with AI) if required. (Note that I am a C# Windows developer not a Linux Rust developer.)

AI Generated Text Below

Summary

This makes the portable/Linux signing path work with Azure Artifact Signing responses and produce NuGet packages that dotnet nuget verify accepts. It keeps the existing Authenticode timestamp behavior, while using the CMS timestamp attribute NuGet expects for package signatures.

Before

A live Azure Artifact Signing response could not be consumed reliably on Linux:

• The signingCertificate field was assumed to be a PEM/DER X.509 certificate. In practice it can be base64 text wrapping a PKCS#7 certificate bag, so both portable sign-pe and code --mode portable failed while parsing the returned certificate payload.
• Some certificate bags have no SignerInfo, so choosing the first embedded certificate is not safe. The observed bag order could put a root/intermediate certificate before the short-lived leaf signing certificate, producing signatures attributed to the wrong certificate.
• Once package signing reached the ZIP-writing stage, NuGet rejected the package with NU3005 because the central-directory version made by / external attributes carried Unix file metadata.
• After clearing ZIP metadata, NuGet rejected the package with NU3000 because the package .signature.p7s used detached CMS content. NuGet package signatures need the id-data content embedded.
• Timestamping used the Microsoft Authenticode RFC3161 unsigned attribute OID. NuGet did not treat that as a package-signature timestamp; it expects id-aa-timeStampToken (1.2.840.113549.1.9.16.2.14).

Changes

• Add a shared Artifact Signing certificate parser in psign-sip-digest that accepts PEM, DER, base64-wrapped data, and PKCS#7 certificate bags.
• Resolve signer certificates from SignerInfo when present, and for certificate-only bags select an unambiguous leaf/code-signing candidate instead of assuming certificate-set order.
• Reuse the shared parser from both the portable digest CLI and the code command.
• Normalize NuGet ZIP central-directory host OS and external attributes when removing or embedding .signature.p7s.
• Let sign_pkcs7_id_data choose detached vs attached CMS content per caller: NuGet uses attached id-data, while App Installer/AuthentiCode-style companion signatures remain detached.
• Add a CMS/PKCS#9 RFC3161 timestamp helper and use id-aa-timeStampToken for NuGet package signatures, while preserving the Microsoft Authenticode timestamp OID for Authenticode paths.
• Add regression coverage for PKCS#7 certificate bags, nested/base64-wrapped Artifact Signing certificate payloads, no-SignerInfo certificate bags, NuGet ZIP metadata normalization, and NuGet timestamp OID behavior.

Testing

Automated:

cargo test -p psign-digest-cli --features artifact-signing-rest --locked --quiet
cargo test -p psign --test code_command --locked --quiet
cargo test -p psign-sip-digest --locked --quiet
cargo test -p psign-opc-sign --locked --quiet

Manual/live, with private Azure Artifact Signing configuration redacted and no service URLs included:

• Built psign-tool on Linux from this branch.
• Signed a PE/DLL payload using an Azure Artifact Signing account/profile; the signature used the expected short-lived organization code-signing leaf certificate rather than a Microsoft root/intermediate certificate.
• Signed a NuGet package containing an inner DLL using psign-tool code --mode portable with Azure Artifact Signing and RFC3161 timestamping.
• Verified the signed package with dotnet nuget verify -v detailed; verification succeeded and NuGet recognized the timestamp.
• Extracted and verified the inner DLL signature with psign-tool portable verify-pe.

Follow-up: NuGet publisher metadata

A later commit adds the NuGet author signed attributes needed for package tooling to classify the primary package signature as an author/publisher signature: signingTime, id-smime-aa-ets-commitmentType with proofOfOrigin, and signingCertificateV2/ESSCertIDv2. This is what allows NuGetPackageExplorer to show the Publisher UI instead of only reporting Signature: Valid.

Additional validation after that commit:

cargo clippy -p psign-sip-digest -p psign-digest-cli -p psign-authenticode-trust -p psign-portable-core -p psign-portable-ffi -p psign-codesigning-rest -p psign-azure-kv-rest --all-targets --locked -- -D warnings
dotnet nuget verify --all <redacted-linux-signed-package>
# Output included: Signature type: Author

[Bradley Grainger (bgrainger)]

The second commit address this problem: NuGet Package Explorer was not showing "Publisher:" metadata as displayed in this screenshot. Previously, only the "Signature ✅" line was showing; now the other metadata (with a link to a Windows certificate dialog) appears.

Reverse-engineered by pointing GPT-5.5 at the https://github.com/NuGetPackageExplorer/NuGetPackageExplorer source code.

AI Text Below

Follow-up: added NuGet author signed attributes required once packages are classified as publisher/author signatures. The final package signature now includes signing-time, id-smime-aa-ets-commitmentType with proofOfOrigin, and signing-certificate-v2/ESSCertIDv2. A redacted live Azure Artifact Signing run produced a package that dotnet nuget verify --all reports as Signature type: Author with the expected publisher subject, which is the metadata path NuGetPackageExplorer uses to show the Publisher UI.

[Marc-André Moreau (mamoreau-devolutions)]

Bradley Grainger (@bgrainger) are the changes on this branch making it work for a successful replacement of your current code signing tools? You could remove the draft flag from this PR. There are some code formatting checks to fix for the CI

[Bradley Grainger (bgrainger)]

a successful replacement of your current code signing tools?

I have not tested it E2E but that's the goal.

The current signing code is here: https://github.com/Faithlife/FaithlifeBuild/blob/20d69035d606ccc4e346512802f51fb3b0152d27/src/Faithlife.Build/DotNetBuild.cs#L551-L590

My intention is to either detect Linux and install psign, or use psign unconditionally on all platforms in that code, then migrate the signing arguments to be compatible with psign. To that end, it would be more convenient to use command-line flags (to psign) for Azure Artifact Signing instead of having to write out a temporary JSON file with some of the arguments. (Edit: reading the code it looks like --artifact-signing-endpoint etc. is supported; my LLM test harness just latched onto --artifact-signing-metadata first.)

One point of friction is that signtool integrates directly with Azure.Identity (see https://github.com/dotnet/sign/blob/0ddd0b9a9be5d5be986e94024642f36d0e2c1a31/docs/artifact-signing-integration.md?plain=1#L7) and psign would need me to do az account get-access-token then pass in --artifact-signing-access-token. I don't think that's a big deal and can probably just use azure/login@v3 and azure/cli@v2 in GHA for those pieces?

Plan:

1. Wait for updated version of Devolutions.Psign.Tool that fixes the issues identified in this PR
2. Update Faithlife.Build to install and use it on Linux
3. Publish pre-release version of Faithlife.Build; switch one private GHA build to ubuntu-latest
4. Test and report back

[Marc-André Moreau (mamoreau-devolutions)]

Bradley Grainger (@bgrainger) a way to do the full testing would be to temporarily modify your real workflow to pull your branch, build psign-tool from source and attempt using it to code sign your nuget without actually publishing it. this is how I got Azure Key Vault signing confirmed to be working by code signing psign-tool with it - there were a couple of things to fix that hadn't been caught until I tried code signing for real.

[Bradley Grainger (bgrainger)]

attempt using it to code sign your nuget without actually publishing it

This was basically what I did. That's how I got the screenshot from NuGet Package Explorer; I iterated on it until it (appeared to) produced the exact same output as a build on Windows.

I'm pretty confident that with this PR's changes I can modify Faithlife.Build to sign with psign and get the correct output; I know I need to modify it to run:

TOKEN=$(az account get-access-token \
  --resource https://codesigning.azure.net/ \
  --query accessToken -o tsv)
"$PSIGN" code --mode portable --verbose \
  --artifact-signing-metadata release/sign/artifact-signing-metadata.json \
  --artifact-signing-access-token "$TOKEN" \
  --timestamp-url http://timestamp.acs.microsoft.com/ \
  --timestamp-digest sha256 \
  --output signed/SomePackage.9.35.0.nupkg \
  release/SomePackage.9.35.0.nupkg

The only thing that hasn't been tested is running it on ubuntu-latest instead of WSL2 (then uploading to GitHub Actions artifacts for manual verification). I can work on that next week (note that 25 May is a U.S. holiday).

[Marc-André Moreau (mamoreau-devolutions)]

Excellent 👍 I have cleaned up and fixed your changes to pass the CI checks in #11 I'll make a new release in the coming days

[Marc-André Moreau (mamoreau-devolutions)]

Bradley Grainger (@bgrainger) I just released 0.4.0, let me know if it works for you when you have the chance

[Bradley Grainger (bgrainger)]

Marc-André Moreau (@mamoreau-devolutions) We are so close! I got psign working with this command-line:

[
	"code",
	"--mode", "portable",
	"--verbose",
	"--artifact-signing-endpoint", "https://wus2.codesigning.azure.net",
	"--artifact-signing-account-name", "...",
	"--artifact-signing-profile-name", certificateProfile,
	"--artifact-signing-access-token", token,
	"--timestamp-url", "http://timestamp.acs.microsoft.com/",
	"--timestamp-digest", "sha256",
	"--output", signedPackagePath,
	packagePath,
]

It was only after doing so that I noticed that the NuGet package itself is timestamped, but the DLLs embedded in it are signed but not timestamped. This is likely an oversight in my last PR so will be repro-ing this E2E and opening a new PR.