Sign Microsoft.Installation library package
#51488
Merged
+62
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a clean commit since I had to merge with main to get the initial CI working during my development branch. Please see the branch `nagilson-dnup-nuget-sign` on origin (nagilson) or upstream (dotnet/sdk) in public if you want the history of these changes. - CI now properly signs the library package for internal consumption. The actual additions: `src/Installer/Microsoft.Dotnet.Installation/Install.sign.proj` -> uses `SignTool` to sign the `dnup library` package with NuGet's Authenticode. `eng/pipelines/templates/jobs/dnup/dnup-library-package.yml` -> now runs the .sign.proj to sign the library package. Notes: - `.sign.proj` is used over `.signproj` as a convention because `code` and other editors don't have xml highlighting for `.signproj` - I considered the ESRP/MicroBuild/SignTool task but felt this was more traceable to call via MSBuild - since the binlog shows all of the 'hidden' arcade magic and variables that flow around. - I was surprised to find that having a very simple `FilesToSign` itemgroup (as many other repos do) and that following the internal documentation for signing a nuget package did not work. `SignTool` was the most robust way I could find to do it. See the drop at https://dev.azure.com/dnceng/internal/_build/results?buildId=2828736&view=artifacts&pathAsName=false&type=publishedArtifacts, download the `dnup-library-packages-unsigned` artifact (which is incorrect, I'm fixing that), clone dotnet/arcade, build, and run `.\artifacts\bin\Microsoft.DotNet.SignCheck\x86\Debug\net472\Microsoft.DotNet.SignCheck.exe -v Detailed -i "drop_path"` or `dotnet nuget verify "drop_path" -v Detailed`
nagilson
force-pushed
the
nagilson-dnup-nuget-sign
branch
from
44440ae to
f637eda
Compare
dsplaisted
approved these changes
Oct 31, 2025
Comment on lines
+5
to
+6
| <_RepoRoot Condition="'$(RepoRoot)' != ''">$(RepoRoot)</_RepoRoot> | ||
| <_RepoRoot Condition="'$(_RepoRoot)' == ''">$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\..\..\'))</_RepoRoot> |
There was a problem hiding this comment.
Is this necessary here? Isn't it set via the Arcade SDK which Directory.Build.props brings in?
If not, then this is probably a bit better (from Arcade):
<RepoRoot Condition="'$(RepoRoot)' == ''">$([MSBuild]::NormalizeDirectory('$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), 'global.json'))'))</RepoRoot>There was a problem hiding this comment.
I agree - this is definitely an improvement. Thanks! It looks like some of the dirs don't populate properly without this - let's improve this in the publishing step so we can move forward.
src/Installer/Microsoft.Dotnet.Installation/Microsoft.Dotnet.Installation.sign.proj
Show resolved
Hide resolved
nagilson
commented
Oct 31, 2025
src/Installer/Microsoft.Dotnet.Installation/Microsoft.Dotnet.Installation.sign.proj
Show resolved
Hide resolved
|
/azp run |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
|
Something disabled the pipeline which runs test checks from running in public... I'll merge this for now as it doesn't change the public CI. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #50621 (there should be another tracking issue for signing the library)
The actual additions:
src/Installer/Microsoft.Dotnet.Installation/Install.sign.proj-> usesSignToolto sign thednup librarypackage with NuGet's Authenticode.eng/pipelines/templates/jobs/dnup/dnup-library-package.yml-> now runs the .sign.proj to sign the library package.We still need to push the package to a public stream for consumption, aka dotnet/tools feed in dnceng-public. That's being tracked here: #51513
Notes:
.sign.projis used over.signprojas a convention becausecodeand other editors don't have xml highlighting for.signprojFilesToSignitemgroup (as many other repos do) and that following the internal documentation for signing a nuget package did not work.SignToolwas the most robust way I could find to do it.For the first example of a successful run, See the drop at https://dev.azure.com/dnceng/internal/_build/results?buildId=2828736&view=artifacts&pathAsName=false&type=publishedArtifacts, download the
dnup-library-packages-unsignedartifact (which is incorrect, and fixed), clone dotnet/arcade, build, and run.\artifacts\bin\Microsoft.DotNet.SignCheck\x86\Debug\net472\Microsoft.DotNet.SignCheck.exe -v Detailed -i "drop_path"or
dotnet nuget verify "drop_path" -v Detailed