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
Hey, the project was deprecated. :( I don't think this issue is worth your time anymore and we don't take participate in hacktoberfest (in case that was the intention). You're always free to make a fork and make any changes, but I do not promise reviewing and merging PRs
I removed the hacktoberfest tag from the repo's tags to not confuse anyone in the future
Upgrading the package that brings it in was tried first and measured: 1.0.0-beta.26120.1 fails with 452 compile errors and clears none of the advisories.
Left: the 6 NU1608.FSharp.Compiler.Service 43.9.300 requires FSharp.Core exactly 9.0.300, while 10.1.302 is resolved — and 10.1.302 is what the .NET 10 SDK itself ships. The resolved version is newer than the constraint, which is ordinary for a package pinned against an older F#. Pinning FSharp.Core down to satisfy it would mean shipping an older compiler than the SDK's, which seems worse than the warning; <NoWarn>NU1608</NoWarn> would hide a real mismatch rather than fix one.
Both of those are your call rather than mine, which is why the issue is still open.
Pin the patched System.Text.Json under the notebook extension #2116: System.Text.Json 8.0.0 under AngouriMath.Interactive, with two high advisories, is pinned to 8.0.6. With that pin, the F# sample and a C# kernel load the extension in the binder image and run with no errors.
Clear the test projects' NuGet warnings #2117: in the test projects, System.Security.Cryptography.Xml and .Pkcs 9.0.6 are pinned to 9.0.21, and NU1608 is suppressed there as it is in the shipped projects.
#1132 settled the NU1608 question from my last comment. It measured the pairing as benign: sixteen of sixteen language features compile against the shipped pair. CompilerServiceWorksTest now carries the check instead of the warning.
What remains is NU1701 in AngouriMathPlot and GraphicExample, for SkiaSharp.Views.WindowsForms 3.119.0 and OpenTK 3.1.0. Both come through ScottPlot.WinForms, and its newest release, 5.1.59, still depends on them. Unless you want those handled here, this issue can be closed.
Activity
u-hashmi commentedon Oct 7, 2024
Hello,
Can I grab this issue?
WhiteBlackGoose commentedon Oct 7, 2024
Hey, the project was deprecated. :( I don't think this issue is worth your time anymore and we don't take participate in hacktoberfest (in case that was the intention). You're always free to make a fork and make any changes, but I do not promise reviewing and merging PRs
I removed the hacktoberfest tag from the repo's tags to not confuse anyone in the future
Fix parsing of pow(), ToBaseN hangs, and three numeric-precision bugs (…
Clear the vulnerable transitive dependency from the terminal (#542) (#…
Rafael-SOWNet commentedon Aug 7, 2026
The security half is fixed in #797 (
b984dc3d); the version-mismatch half wants your call.Fixed. The 48
NU1903warnings were not a version mismatch but a vulnerability:Microsoft.DotNet.Interactive.FSharpbringsSystem.Security.Cryptography.Xml9.0.6, which carries eight distinct known high-severity advisories (GHSA-23rf-6693-g89p, GHSA-37gx-xxp4-5rgx, GHSA-6588-8gv4-xfgh, GHSA-8q5v-6pqq-x66h, GHSA-cvvh-rhrc-wg4q, GHSA-g8r8-53c2-pm3f, GHSA-mmjf-rqrv-855v, GHSA-w3x6-4m5h-cxqf). A direct reference to the patched 9.0.18 pulls it forward: 48 → 0, build still succeeds, Terminal 7/7 and F# wrapper 130/130.Upgrading the package that brings it in was tried first and measured:
1.0.0-beta.26120.1fails with 452 compile errors and clears none of the advisories.Left: the 6
NU1608.FSharp.Compiler.Service 43.9.300requiresFSharp.Coreexactly9.0.300, while10.1.302is resolved — and 10.1.302 is what the .NET 10 SDK itself ships. The resolved version is newer than the constraint, which is ordinary for a package pinned against an older F#. PinningFSharp.Coredown to satisfy it would mean shipping an older compiler than the SDK's, which seems worse than the warning;<NoWarn>NU1608</NoWarn>would hide a real mismatch rather than fix one.Both of those are your call rather than mine, which is why the issue is still open.
Stop packing a library nobody publishes (#542) (#960)
One issue template, and the labels that are left are the ones in use (#…
Pin the patched System.Text.Json under the notebook extension (#2116)
Drop the unused Spectre.Console.ImageSharp reference from amcli (#2115)
Clear the test projects' NuGet warnings (#2117)
Rafael-SOWNet commentedon Oct 25, 2026
Three more PRs on this. Every project now restores with no NuGet warning except the two Windows samples:
amclishippedSixLabors.ImageSharp3.1.12, which has five advisories, throughSpectre.Console.ImageSharp. Nothing used that package, so the reference is gone (amcli ships a vulnerable SixLabors.ImageSharp through a reference it does not use #2114).System.Text.Json8.0.0 underAngouriMath.Interactive, with two high advisories, is pinned to 8.0.6. With that pin, the F# sample and a C# kernel load the extension in the binder image and run with no errors.System.Security.Cryptography.Xmland.Pkcs9.0.6 are pinned to 9.0.21, andNU1608is suppressed there as it is in the shipped projects.#1132 settled the
NU1608question from my last comment. It measured the pairing as benign: sixteen of sixteen language features compile against the shipped pair.CompilerServiceWorksTestnow carries the check instead of the warning.What remains is
NU1701inAngouriMathPlotandGraphicExample, forSkiaSharp.Views.WindowsForms3.119.0 and OpenTK 3.1.0. Both come throughScottPlot.WinForms, and its newest release, 5.1.59, still depends on them. Unless you want those handled here, this issue can be closed.