KaitaiStruct.Runtime.CSharp v0.10.0 contains indirect vulnerable references

[Kielek]

.NET9 will bring extended audit for vulnerable references including all indirect references.
It can be replicated also on older versions by compiling projects with following options

    <NuGetAudit>true</NuGetAudit>
    <NuGetAuditMode>all</NuGetAuditMode>
    <NuGetAuditLevel>low</NuGetAuditLevel>

Preparing OTel contrib repository for this, reveals that KaitaiStruct.Runtime.CSharp v0.10.0 brings

• 'System.Net.Http' 4.3.0 has a known high severity vulnerability, GHSA-7jgj-8wvc-jh57
• 'System.Text.RegularExpressions' 4.3.0 has a known high severity vulnerability, GHSA-cmhx-cq75-c4mj

The issue is valid for all available targets netstandard1.3 and net4.5.

Fix
Drop support both for netstandard1.3 and net4.5. Replace it by net6.0 and net462. It should cover all supported .NET versions. If needed, it can be extended also by netstandard2.0.
Next step is release never version.

Workaround
Manually pin packages to non-vulnerable version.

[generalmimon]

.NET9 will bring extended audit for vulnerable references including all indirect references.

It would be nice to have this audit running periodically in a CI pipeline so that we know about this kind of issues in the future, but setting up any automation takes some work.

Fix
Drop support both for netstandard1.3 and net4.5. Replace it by net6.0 and net462. It should cover all supported .NET versions.

I agree, it probably doesn't make sense targeting unsupported versions. I can see at https://endoflife.date/dotnet that .NET 6 is actually also unsupported at the moment, but only as of fairly recently (November 2024), so let's keep supporting it for a while. According to https://endoflife.date/dotnetfx, .NET Framework 4.6.2 is the oldest supported version by a large margin (> 2 years), so that's a clear cut.

If needed, it can be extended also by netstandard2.0.

I have no idea if anyone needs that. I get from https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/ that .NET Standard is kind of a legacy thing, so I guess it's fine to drop support for it now and only consider restoring it if someone specifically requests it.

[Arlorean]

I have no idea if anyone needs that. I get from https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/ that .NET Standard is kind of a legacy thing, so I guess it's fine to drop support for it now and only consider restoring it if someone specifically requests it.

My future plan was to use KaitaiStruct with C# for Unity, which supports .NET Standard 2.0/2.1 currently. Unity might go full .NET (Core) at some point but for now it's still tied to Mono. If we could keep it working for it then it would be great, but if it's essential to drop .NET Standard I'd understand. Thanks.

[generalmimon]

@Arlorean:

My future plan was to use KaitaiStruct with C# for Unity, which supports .NET Standard 2.0/2.1 currently. Unity might go full .NET (Core) at some point but for now it's still tied to Mono.

Thanks for pointing this out. In that case, should we add netstandard2.0 to the list of target frameworks in the .csproj file, then?

kaitai_struct_csharp_runtime/kaitai_struct_runtime_csharp.csproj

Line 4 in 7e627dd

<TargetFrameworks>net6.0;net462</TargetFrameworks>

Or perhaps we could only target netstandard2.0 instead? As I understand, .NET Standard represents the "lowest common denominator" of various .NET implementations (including .NET 6 and .NET Framework 4.6.2, see https://dotnet.microsoft.com/en-us/platform/dotnet-standard#versions), so it might be unnecessary to target net6.0;net462 specifically when <TargetFrameworks>netstandard2.0</TargetFrameworks> will suffice.

According to https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0#when-to-target-netx0-vs-netstandard:

When to target netx.0 vs. netstandard

For existing code that targets .NET Standard 2.0 or later, there's no need to change the TFM to net8.0 or a later TFM. .NET 8 and .NET 9 implement .NET Standard 2.1 and earlier. The only reason to retarget from .NET Standard to .NET 8+ would be to gain access to more runtime features, language features, or APIs. For example, to use C# 9, you need to target .NET 5 or a later version. You can multitarget .NET and .NET Standard to get access to newer features and still have your library available to other .NET implementations.

Given how minimal our runtime library is, I don't think we need or would somehow benefit from recent APIs, so targeting only .NET Standard 2.0 seems fine based on this description.

[generalmimon]

Or perhaps we could only target netstandard2.0 instead?

For the record, I was browsing https://www.nuget.org/packages and found a quite popular NuGet package called coverlet.collector, which does exactly that - see https://www.nuget.org/packages/coverlet.collector/6.0.2#supportedframeworks-body-tab and coverlet.collector.csproj:3:

    <TargetFrameworks>netstandard2.0</TargetFrameworks>

And in fact, they used <TargetFrameworks>netstandard2.0;net6.0</TargetFrameworks> before, but then reduced it to just netstandard2.0 due to certain issues, see coverlet-coverage/coverlet#1636 (comment):

Changing the tfm of core to only netstandard2.0 fixes the problem.

So it even seems like a more robust option.

[generalmimon]

.NET docs actually include a nice summary with recommendations which .NET frameworks to target: https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting

Again, it pretty much says that netstandard2.0 is all we need.

[Arlorean]

The main advantage of .netstandard2.1 is that it includes full support for Span<T> which is the ideal structure to return, in many cases, when parsing files using Katai Struct. It allows memory allocation free returning of data directly from file buffers. You can even do the equivalent of a C++ reinterpret_cast to seamlessly read a byte stream as a float stream, with no memory allocation/copying at all. It's all still typesafe and bounds checked too. Just awesome!

Failing that .netstandard2.0 would provide the highest level of cross platform/runtime compatibility, which is the best target for a library you want to be able to use anywhere, even on older versions of the .NET Framework.