You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to #44197 I did a broader scan of the SDK to find what other binaries it might contain from previous servicing bands. These don't have CVE's but if they did, we'd need to coordinate cross-release flow, or upgrade to newer packages.
I wonder if for many of these net4x copies if the answer is to exclude the binaries and rely on the copy from MSBuild or VS.
For the case where the buildhost is pulling in 8.0.0 copies of packages - the fix here might be to have a version of that which targets 9.0. @jaredpar suggested that in #44197 (comment)
Checking on further references to out-of-date package versions I found the following old packages mentioned in deps files:
Ideally these would not be present in deps if they don't represent actual dependencies shipping in the SDK. Once we have supplied by platform it will be easier to clean these deps files up, but we may want to do something before then if any of these are likely to be serviced (like System.Text.Json).
To Reproduce
Examine the content of the SDK for stale versions. I have a tool that's dumping these that I can share.
Exceptions (if any)
None
The text was updated successfully, but these errors were encountered:
For the case where the buildhost is pulling in 8.0.0 copies of packages - the fix here might be to have a version of that which targets 9.0. @jaredpar suggested that in #44197 (comment)
It looks like a lot of these are in net472 builds and they're in msbuild tasks. That is a place where msbuild (at least ideally) should be controlling the version of SCI, SRM, etc ... that is loaded. Should we consider changing msbuild to treat those as part of the platform and then have tasks stop distributing them entirely?
For the source generator cases we should not be deploying SCI at all. Compiler will load that so we can fix this by changing the builds to simply stop deploying that.
Describe the bug
Similar to #44197 I did a broader scan of the SDK to find what other binaries it might contain from previous servicing bands. These don't have CVE's but if they did, we'd need to coordinate cross-release flow, or upgrade to newer packages.
Here's what I found:
I wonder if for many of these
net4x
copies if the answer is to exclude the binaries and rely on the copy from MSBuild or VS.For the case where the buildhost is pulling in 8.0.0 copies of packages - the fix here might be to have a version of that which targets 9.0. @jaredpar suggested that in #44197 (comment)
Checking on further references to out-of-date package versions I found the following old packages mentioned in deps files:
Ideally these would not be present in deps if they don't represent actual dependencies shipping in the SDK. Once we have supplied by platform it will be easier to clean these deps files up, but we may want to do something before then if any of these are likely to be serviced (like System.Text.Json).
To Reproduce
Examine the content of the SDK for stale versions. I have a tool that's dumping these that I can share.
Exceptions (if any)
None
The text was updated successfully, but these errors were encountered: