Could this library also target .NET standard 2.0 explicitly? (Or maybe even .net 6 and .net 7)
EraYaN opened this issue · 4 comments
That would resolve a bunch of unsafe dependencies from .NET Standard 1.6.1 and earlier. (Mostly in System.IO.Compression.ZipFile, System.Net.Http, System.Net.Sockets and System.Text.RegularExpressions)
<TargetFramework>netstandard1.0</TargetFramework> -> <TargetFrameworks>netstandard1.0;netstandard2.0</TargetFrameworks> ought to do it.
(And also could add the jxl type in the same update, now that iOS and Safari are going to support it.)
Can you describe the problem you're seeing exactly? I'm not clear what the problem is.
Also, feel free to raise a PR for the type you've mentioned.
netstandard.library 1.6.1 is the default if you restore this in any modern .NET application. And instead of pinning all the transitive dependencies to get rid of a bunch of CVEs, if this library targets .NET standard 2.0 directly it will restore that one and the vulnerabilities are resolved.
For reference:
CVE-2018-8416
CVE-2017-0247
CVE-2017-0248
CVE-2017-0249
CVE-2018-8292
CVE-2017-0256
CVE-2019-1301
CVE-2019-0820
Almost all in the 4.3.0 version in a bunch of the System.* namespace packages. .NET Standard targets the slightly newer *.1 and *.2 etc releases with fixes. I'll have a look at making a PR for both the versions and some of the new MimeTypes.
Sorry I still don't understand the exact issue you're seeing. Please can you respond with precise steps for reproducing the problem? Without steps to reproduce I can't do much with this issue. Thanks.
I'm not sure what you are looking for. .NET Standard 1.6.1 depends on old dependencies. There is nothing to reproduce, this is a fact, the dependencies are listed on Nuget.org. This is a problem, those old dependencies are vulnerable to certain attacks (see included list of CVEs above).
Including these dependencies will cause dotnet/nuget to resolve to these older versions unless you pin them explicitly. But the correct and much friendlier solution for library consumers is to just multi target the actual library (using the TargetFrameworks vs TargetFramework item in the csproj), so anyone on modern versions of .NET (4.6.1 and later) does not have to worry about shipping those vulnerable binaries at all or pinning them explicitly (actually on .NET standard 2.0 it has far fewer dependencies in general, reducing publish size). If the support burden is to much for this project we can always just maintain an internal fork of course, but obviously I'd much rather see upstream update and start multi targeting at least one of the more modern targets (.NET Stadard 2.0 would be sufficient).