Downgrade SIL.BuildTasks to depend on SIL.Core v. 9.0.0

[tombogle]

This re-introduces the build-time dependency on Newtonsoft.Json 11.0.1, which has a real DoS vulnerability: GHSA-5crp-9r3c-p9vr, via deeply-nested JSON causing stack overflow or high CPU/memory (fixed in 13.0.1). This is unfortunate, since Dependabot will continue to flag this in every product that uses SIL.BuildTasks.

In the actual shipped-product runtime-risk sense, there is essentially no actual vulnerability. Because the package is IsTool=true, neither SIL.BuildTasks' nor SIL.Core's DLLs get added as compile references or copied into the consumer's bin/publish output — they're only loaded into the MSBuild process itself via UsingTask, on the build machine, at build time. The vulnerable code (Newtonsoft.Json deserializing deeply-nested JSON causing a DoS) never ships inside Bloom's actual installed product, and nothing in SIL.BuildTasks' own tasks (file editing, WiX GUIDs, changelog stamping, NUnit wrapping) feeds untrusted external JSON through it during a build.

---

This change is 

[github-actions]

Test Results

  4 files  ±0   66 suites  ±0   32s ⏱️ +8s
222 tests ±0  222 ✅ ±0  0 💤 ±0  0 ❌ ±0 
444 runs  ±0  442 ✅ ±0  2 💤 ±0  0 ❌ ±0 

Results for commit 84526d8. ± Comparison against base commit 764887c.

♻️ This comment has been updated with latest results.

[andrew-polk]

@andrew-polk reviewed 2 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on tombogle).

[tombogle]

@rmunn I just saw that #81 has been approved. So if you want to merge that first and include it with this release to fix Bloom, say so. (It will require a little work in CHANGELOG.md to get things right.)

[rmunn]

@rmunn I just saw that #81 has been approved. So if you want to merge that first and include it with this release to fix Bloom, say so. (It will require a little work in CHANGELOG.md to get things right.)

@tombogle Done, and rebased this PR's commits on top of the #81 merge. I tweaked the CHANGELOG to reflect the correct changes at each step. I put the ### SECURITY section at the bottom since it seems from the top-level comment that the sections are arranged alphabetically, but it's possible it should come first before ADDED just so it's the first thing people see? It's not a very long changelog entry for 3.2.2 so it probably doesn't matter, so I've left it as-is. Please feel free to edit it before merging if you feel it's needed.

P.S. I also bumped the CHANGELOG date for 3.2.2 from 2026-09-01 to 2026-09-02, since it's still September 1st in parts of the US at the moment but it seems likely that the release won't actually happen until September 2nd or later.

[rmunn]

A long-term solution might be to change the Mono.Unix dependency in SIL.Core to only apply to the netstandard2.0 build, and remove that dependency from the net461/net462/net472 build (whichever version of .NET Framework we end up on). But this should work for now.

[rmunn]

Worth noting that Microsoft.Build.Tasks.Core version 15.9.30 was the last version to build for a .NET Framework 4.6 version. From Microsoft.Build.Tasks.Core version 16 onwards that package depends on .NET Framework 4.7.2. So it's possible we will get some errors when we try to use SIL.BuildTasks from a net461 or net462 build (such as ChorusHub). However, #82 bumped the Microsoft.Build.Tasks.Core dependency from 17 to 18, so the net472 dependency issue was already present before SIL.Core was bumped.

Therefore, I'm not going to suggest downgrading the Microsoft.Build.Tasks.Core dependency down to 15 in this PR, because that .NET Framework version mismatch already existed before the SIL.Core version bump that this PR is intended to address. (The Microsoft.Build.Tasks.Core dependency was introduced in SIL.BuildTasks release 3.1.2-beta0002).

[tombogle]

SIL.BuildTasks' task assemblies aren't compiled into the product; they're loaded via <UsingTask> into whatever process is doing the build (MSBuild.exe or dotnet build's host), which runs on the .NET Framework/SDK installed on the build machine - not on the TargetFramework the project declares. A net461-targeting project can still be built by an MSBuild host running on 4.7.2+/4.8, with no relationship between the two.

So the real risk isn't "does the product target net46x" - it's "is the build machine itself frozen below 4.7.2," which would need an older VS/Build Tools install. Given #82 already bumped Microsoft.Build.Tasks.Core to 18 with no reported breakage, that doesn't seem to be happening in practice. I'd be surprised if any of our build agents/tooling are operating on .net 4.6.x.

(Even then, .NET Framework doesn't always hard-fail at load time just because a dependency was compiled against newer reference assemblies - it can still work unless a not-actually-present API gets called.)

[tombogle]

SIL.BuildTasks' task assemblies aren't compiled into the product; they're loaded via <UsingTask> into whatever process is doing the build (MSBuild.exe or dotnet build's host), which runs on the .NET Framework/SDK installed on the build machine - not on the TargetFramework the project declares. A net461-targeting project can still be built by an MSBuild host running on 4.7.2+/4.8, with no relationship between the two.

So the real risk isn't "does the product target net46x" - it's "is the build machine itself frozen below 4.7.2," which would need an older VS/Build Tools install. Given #82 already bumped Microsoft.Build.Tasks.Core to 18 with no reported breakage, that doesn't seem to be happening in practice. I'd be surprised if any of our build agents/tooling are operating on .net 4.6.x.

(Even then, .NET Framework doesn't always hard-fail at load time just because a dependency was compiled against newer reference assemblies - it can still work unless a not-actually-present API gets called.)

[tombogle]

Great idea. I have filed an issue to that effect.

[tombogle]

@tombogle resolved 1 discussion.
Reviewable status: 1 of 2 files reviewed, all discussions resolved (waiting on andrew-polk).