[karlspace]

Why

Dependabot alerts #1 and #2 (medium): Microsoft.Build.Tasks.Git 10.0.300 is affected by GHSA-23fw-v26w-5fgq / CVE-2026-62900 (information disclosure; affected 10.0.300 - 10.0.301, first patched 10.0.303). It is not referenced directly; it comes in through Microsoft.SourceLink.GitHub 10.0.300 (central package management, Directory.Packages.props).

What

Two atomic commits:

1. ci(release): enabled assembly signing for the PR package validation: every PR run of Validate Package (PR) / Build & Pack has failed for months. Package validation compares against the signed 2.0.0 baseline, but the PR job packed unsigned assemblies, so ApiCompat reported CP0003 (public key token 9abfc39dbb2dd76a vs null) for every library. pr-validate now passes sign-assembly: true, the same as the publish job. Secret exposure stays the same: the validate job already writes the same DOTNET_SIGNKEY_BASE64 key for PR builds via snk-file-path. Runs without the key (Dependabot, forks) still fall back to an unsigned build, as before.
2. build(deps): updated Microsoft.SourceLink.GitHub to 10.0.303: this is the patched release of the same SDK feature band. Its nuspec depends on Microsoft.Build.Tasks.Git 10.0.303 and Microsoft.SourceLink.Common 10.0.303 (and System.IO.Hashing 10.0.11), so restore resolves the fixed version without any forced transitive pin or override.

Both commits use non-release types (ci, build) on purpose. SourceLink is a build-time tool (PrivateAssets="All", developmentDependency): it never becomes a dependency of the published packages and leaves the shipped code and API unchanged. This does not mean the merge cuts no release. See the next section.

Owner decision: merging this PR publishes 2.2.1

Merging this PR will cut and publish v2.2.1 of all 5 packages to NuGet.org and GitHub Packages. The release does not come from the two commits here. It comes from a release that is already waiting on main:

• main has 4 commits since v2.2.0 (2026-07-07). One of them, 73d80e2 fix(ci): added the missing permissions block, is a fix. .github/config/release/semantic-release.json sets no releaseRules, so the template's standard rules apply, and they count fix as a patch.
• All 4 commits changed only .github/**, which the push trigger of this workflow ignores (paths-ignore: .github/**, *.md, docs/**). That is why no release run has started since v2.2.0.
• This PR changes Directory.Packages.props, so its merge starts the push pipeline: Build & Test, then Create Release (semantic-release finds 73d80e2 and cuts 2.2.1), then Publish (signed, push-to-nuget: true, push-to-github: true). The PR title and the merge method (squash, merge commit, rebase) do not change that.

What 2.2.1 would contain:

• The same library source as 2.2.0: nothing under src/ has changed since v2.2.0. It is rebuilt with SourceLink 10.0.303.
• A higher dependency floor for CRM, DMS, ERP and Shipping: BAUERGROUP.Shared.Core >= 3.1.0 instead of >= 3.0.8. Directory.Packages.props floats it as 3.*, and 3.1.0 (published 2026-09-15) is now the newest 3.x. The pack in this PR's CI already resolved 3.1.0 and passed package validation (see the nuspecs in the nuget-packages artifact of run 38095451457). Consumers still on Shared.Core 3.0.x would move to 3.1.0 through the transitive dependency.
• Release notes and a CHANGELOG.md entry for 73d80e2.

Options:

1. Merge now and accept 2.2.1. Alerts deps(dotnet): Bump BAUERGROUP.Shared.Core from 3.0.0 to 3.0.4 #1 and deps(dotnet): Bump the testing group with 1 update #2 close after the merge.
2. Hold the merge. Alerts deps(dotnet): Bump BAUERGROUP.Shared.Core from 3.0.0 to 3.0.4 #1 and deps(dotnet): Bump the testing group with 1 update #2 stay open. The pending 2.2.1 does not go away: the next merge to main that touches anything outside .github/**, *.md and docs/** cuts it, with the same Shared.Core 3.1.0 floor.

Proof it does not break

• Local dotnet restore: all 7 projects (5 libraries, 2 test projects) resolve Microsoft.Build.Tasks.Git/10.0.303, Microsoft.SourceLink.Common/10.0.303 and Microsoft.SourceLink.GitHub/10.0.303 in project.assets.json. 10.0.300 is gone from the package folder.
• Local dotnet build -c Release: 0 errors. The only warnings are the 3 existing CS0612 warnings (ERPProduct.VAT obsolete), the same as on main.
• PR CI, run 38095451457 on e89161b, all green:
  • Build & Test / Build .NET (ubuntu-latest, 10.0.x): restore fetched microsoft.build.tasks.git/10.0.303. The solution built and 34/34 tests passed (32 unit tests, 2 integration tests).
  • Validate Package (PR) / Build & Pack: SNK signing was active (-p:SignAssembly=true). Build had 0 errors. dotnet pack produced all 5 .nupkg + 5 .snupkg (2.2.0-pr.35), and package validation against the signed 2.0.0 baseline passed. The CP0003 failure that every earlier PR run hit is gone.
  • The packed nuspecs (nuget-packages artifact) have no SourceLink dependency and a clean repository URL. CRM, DMS, ERP and Shipping depend on BAUERGROUP.Shared.Core 3.1.0 (see the owner decision above).
  • CodeQL (actions, csharp), GitGuardian and NuGet dependency submission: pass. No startup_failure.
• The ApiCompat notes "Could not resolve reference 'System.Security.Permissions.dll' ... netstandard2.0" (10 lines) are informational and already appear in earlier PR runs on main's dependency set. This change did not introduce them.

Left open

• Dependabot PRs still fail Validate Package (PR) with CP0003. Dependabot-triggered runs get only Dependabot secrets, so they fall back to unsigned builds. One fix: an admin adds DOTNET_SIGNKEY_BASE64 as a Dependabot secret (owner decision). Until then, the auto-merge in dependabot-maintenance.yml, which requires this workflow to pass, merges nothing.
• deps(dotnet): Bump Microsoft.CodeAnalysis.BannedApiAnalyzers and 3 others #13 (Dependabot microsoft group) also moves SourceLink, to 10.0.401. It will rebase on top of this PR and still needs its own review: it includes a BannedApiAnalyzers 4.x to 5.x major update.

[github-actions]

🎉 This PR is included in version 2.2.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀