Open janstaelensskyline opened 2 weeks ago
Hi @janstaelensskyline unfortunately, those versions of Windows are both out of the mainstream support lifecycle, so there's not a lot we can do for those.
That said Sign CLI carries its own copies of the Authenticode signing libraries and that activation context should be forcing the tool to use those versions instead of the ones the OS carries. @dtivel, looks like there may be an issue here? Can we confirm that the correct libraries are being loaded and used at runtime?
Hello @clairernovotny , understood. Do you have a list with the mainstream support for what version of windows OS is supported and part of your QA cycle for the signing of .nupkg?
Update on this issue. I've continued debugging this on my end. It's been strange... I tested running the AzureSign Tool on an assembly and the KeyVaultSign tool on a .nupkg directly with our same azure keyvault settings and both those tools worked on every PC and Server. Only the sign tool itself kept failing.
Using the exact same sign command as mentioned in the first post, version of the tool and the same .nupkg package. All the servers & pc's have .NET8 installed.
On azure pipelines using windows host: WORKS On Github pipelines using windows host: WORKS
On 2 Pc's with Windows 10: FAILS WITH ERROR -2147012744
On 1 PC with Windows 11: FAILS WITH ERROR -2147012744
On Windows Server 2019: FAILS WITH ERROR -2147012744
On Windows Server 2022: FAILS WITH ERROR -2146762749
the command suddenly started working on 2 PC's with Windows 10: 1 PC with Windows 11:
Both the servers are still failing (2019 and 2022) but with different error codes.
I spend a while checking to see what 'changed' on the PC's that didn't on the servers but I'm not finding much. I saw a windows update for microsoft defender: KB2267602. But when I installed that on the server nothing changed. There was no reboot or restart for one of the win10 pc's for over 7 days so I'm not immediately seeing other windows updates being a factor there.
On applications I didn't see any updates that every PC had and that the servers might've been missing.
Currently I'm not able to really figure this out. I'll setup our self-hosted jenkins pipelines to use the NuGetKeyVault tool directly for now, but we'd prefer to use the same dotnet sign tool on all our CI/CD.
Describe the Bug
Environments:
When executing
dotnet sign
on a.nupkg
file using Azure Key Vault, we encounter the following error:0x80072EE8
dotnet.exe
process with signing also fails.Interestingly, this issue does not occur when running the code from an Azure Pipeline on a provided Windows machine. It suggests we might be missing a prerequisite on our personal computers. It does happen on our Jenkins setup running on the above specified windows 2019 server.
After some investigation, it appears the error originates from deep within the code, specifically from calls to the Windows OS to sign the assemblies inside the
.nupkg
.The problem is that I'm not familiar enough with the
SignerSignEx3
WinAPI call and it seems like documentation will be private to Microsoft. At this point, it's likely that I've gone too deep and am missing a more obvious issue.Repro Steps
.nupkg
that includes.net462
assemblies.dotnet
is a class that startsdotnet.exe
as a process with the provided string as an argument):Expected Behavior
Expecting to see a signed
.nupkg
with all content signed.Actual Behavior
Signing starts, then it retries over and over again until it throws an exception.
Standard Output:
Additional Context
dotnet --info
.NET SDKs Installed
.NET Runtimes Installed
Other Architectures Found
Environment Variables
global.json File
Learn More
Download .NET