Fix package signing verification #1761
Conversation
Bump sign to 0.9.1-beta.23530.1.
martincostello
added
CI/build
bug fix
dependencies
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1761 +/- ##
=======================================
Coverage 84.53% 84.53%
=======================================
Files 307 307
Lines 6777 6777
Branches 1043 1043
=======================================
Hits 5729 5729
Misses 839 839
Partials 209 209
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Test that #1761 resolves the issue.
|
Can we add this tool to dotnet-config.json file? |
|
We could, which we keep it updated with dependabot, but (currently) have no way of testing the signing steps change-to-change to validate that updating the pinned version doesn't break anything. For now I'm just concentrating on resolving the root problem. |
Check out the repository so our `global.json` version determines what version of the .NET SDK is installed.
Pass the `--verbosity` flag with a level of `Warning` (the default) unless GitHub Actions debugging is enabled, in which case specify `Debug`.
Checkout Polly to a subdirectory when being used to obtain the .NET SDK version.
Avoid cloning Polly to get the .NET SDK version to use, and instead output the value from the actions/setup-dotnet step in the build job.
Use `github.repository` to get the repository name instead of hard-coding it.
Use fork of vcsjones/AuthenticodeLint that is compiled against vcsjones/AuthenticodeExaminer from source to resolve issues with validating Authenticode signatures of the DLLs.
martincostello
added
the
github_actions
|
@martintmk I've logged bugs against the associated tools we use to validate the packages in CI. Once we have some feedback on those (and ideally some upstream fixes), then we can look at revisiting the automation to have a more regular feedback loop that doesn't need is to actually try and publish something to NuGet.org. |
Changes verified using #1762: successful valid signing
Once 8.1.0 has been successfully published to NuGet.org, I'll create follow-up issues with the relevant tools/repos to hopefully resolve the underlying issue without us having to build the linter from a custom fork/branch.Reported issues: