Bump SourceLink past CVE-2026-62900, and System.IO.Hashing with it - #3210
Merged
Conversation
NuGet audit started failing every build yesterday: error NU1902: Package 'Microsoft.Build.Tasks.Git' 10.0.201 has a known moderate severity vulnerability GHSA-23fw-v26w-5fgq was published on 2026-09-08. We pull Build.Tasks.Git transitively via Microsoft.SourceLink.GitHub, which was pinned at 10.0.201 - and the advisory lists the whole 10.0.200-10.0.204 band as affected with no patched version in that band, so there is nothing to move to inside it. Going to 10.0.401 takes us past every affected range. That in turn wants System.IO.Hashing 10.0.12, where we pinned 10.0.5, so without bumping that too the restore trades NU1902 for NU1605. Note this is consumer-visible: System.IO.Hashing is a real dependency of the library, so the floor it declares moves from 10.0.5 to 10.0.12 on every target framework. SourceLink itself is build-time only and stays out of the package's dependency groups. SourceLink 10.0.112 would have fixed the advisory without touching System.IO.Hashing at all - it has no dependency on it - but that means moving back a servicing band, so it is only the answer if the floor bump is unwelcome.
Merged
mgravell
added a commit
that referenced
this pull request
Sep 10, 2026
Three consumer-visible changes in this cycle that a build bump would under-signal: - net6.0 dropped from TargetFrameworks (#3208). Anyone still targeting it does not get a worse version, they get no version. - System.IO.Hashing's declared floor moved from 10.0.5 to 10.0.12 (#3210), on every target framework. - ScriptEvaluateReadOnly now genuinely sends EVAL_RO where the server and command map allow it, so a script that *writes* on that API starts being rejected on 7.0+ where plain EVAL used to let it through. Plus the new surface from #3201 - RespResult, RedisKeyOrValue, the *Resp family, and the un-gated RespReader API - which is additive but substantial. assemblyVersion stays at 3.0 deliberately: it is decoupled from the package version precisely so that a minor bump is not a binding break, and moving it would be one for anyone with a compiled reference or a binding redirect. Confirmed against a local pack - package 3.2.0, assembly still 3.0.0.0. versionHeightOffset went with it: it was scoped to 3.1 via versionHeightOffsetAppliesTo, so it stopped applying the moment the version changed. Verified the computed version is identical with and without it.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
NuGet audit started failing every build yesterday:
GHSA-23fw-v26w-5fgq (CVE-2026-62900) was published 2026-09-08, so this is new and unrelated to any code change. We pull
Microsoft.Build.Tasks.Gittransitively viaMicrosoft.SourceLink.GitHub, pinned at10.0.201.The awkward part is that the advisory lists the whole
10.0.200–10.0.204band as affected with no patched version in that band, so there is nothing to move to inside it:= 8.0.0>= 10.0.102, <= 10.0.11010.0.111>= 10.0.200, <= 10.0.204>= 10.0.300, <= 10.0.30110.0.30310.0.401is past every affected range. It wantsSystem.IO.Hashing 10.0.12where we pinned10.0.5, so bumping SourceLink alone just tradesNU1902forNU1605(package downgrade) — hence both move together.Consumer-visible
System.IO.Hashingis a real dependency of the library, so the floor it declares moves from10.0.5to10.0.12on all six target frameworks. Confirmed by unpacking the built nupkg. SourceLink is build-time only and stays out of the package's dependency groups, so that half is invisible to consumers.Alternative, if the floor bump is unwelcome
Microsoft.SourceLink.GitHub 10.0.112clears the advisory (it is past10.0.111) and has noSystem.IO.Hashingdependency at all, so it fixes CI with a one-line change and no consumer impact. The cost is moving back a servicing band,10.0.2xx→10.0.1xx. I verified that route too: restore, build and pack are all clean on it. Say the word and I will swap.Verified
dotnet restore Build.csproj— clean, noNU1902, noNU1605dotnet build Build.csproj -c Release /p:CI=true— 0 warnings, 0 errorsdotnet pack— succeeds; nuspec inspected for the dependency groups above