.NET Core September 2019 Update - 2.2.7 and 2.1.13

[leecow]

2.1.13 Release Notes
2.1.13 Download

2.2.7 Release Notes
2.2.7 Download

Blog posts

.NET Core

Please report any issues you find with 2.1.13 or 2.2.7, either responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• aspnet/Home - for ASP.NET Core questions
• aspnet/EntityFrameworkCore - for Entity Framework Core questions
• dotnet/cli - for CLI tools and questions
• dotnet/corefx - for API issues and questions
• dotnet/coreclr - for runtime issues
• dotnet/core-setup - for installer issues

[williamdenton]

hi @leecow the first four links above don't go to the right place (404)

Also the release notes need a for the <h3> on CVE-2018-8269: Denial of Service Vulnerability in OData for mark down to render properly

👍

[leecow]

Thanks, @williamdenton and sorry for that. Links fixed.

[martincostello]

I couldn't see a discussion issue for dotnet/announcements#121, so I'll ask here instead. For clarity, is 3.0 preview 9 unaffected by CVE-2019-1301?

[BJMdotNET]

The page https://github.com/dotnet/core/tree/master/release-notes was not updated (still mentions 2.2.6 and 2.1.12 as the latest releases).

Also, I don't know who maintains https://dotnet.microsoft.com/download/dotnet-core/2.2 , but it mentions "Visual Studio 2017 (v16.2)" which should be "Visual Studio 2019 (v16.2)".

[bmorenc]

These release notes state that System.Net.Sockets is vulnerable at 4.3.0 and secure at 4.3.1 however there is no version 4.3.1 published on Nuget.org. What am I missing here?

[bmorenc]

How can I see the complete list of latest (secure) individual package versions across corefx and aspnetcore for a given .net core release number? In other words, my projects are on net core 2.1.13, net standard 2.0 and net framework 461 but my nuget package references in csproj files are all over the place. I don't want my team's blindly going to 2.2 or 3.0 versions of packages so they cannot simply grab the latest version. And the package manager is not enforcing any target limitations on the versions it will accept. Thank you for any help.

Bryan

[bmorenc]

@leecow @vivmishra Any help here?

[vivmishra]

@scalablecory & @davidsh for System.Net.Sockets version question.

@bmorenc, we have the list of packages that were updated for a release (see the bottom of the release notes) - this may help you to at least know what changed. 2.1.13 Release Notes
Just to be clear -- from our perspective the latest set of 2.1 and 3.0 packages will always be the most secure and recommended. In only a very odd case (say where we have uncovered a bad regression) would we not recommend picking the latest.

Cc @terrajobst for guidance on complete list of packages.

[bmorenc]

@vivmishra thank you for responding and pulling in others for the security patch question on System.Net.Sockets.

Understanding which versions are associated with say 2.1.13 is quite easy for the packages that follow the framework versioning (Microsoft.Extensions.DependencyInjection 2.1.1).

The particularly challenging ones are those that don't such as the System.Net.Sockets example. I've been doing some more exploring on my end and it seems like even the latest 3.1.x based Nuget packages contain the older DLLs compatible with previous targets ensuring that no matter which target including multiple targets, I'll have the latest dll for each. However, if I pull say System.componentmodel.annotations 4.7.0 but I am only targeting netstandard 2.0 and not netstandard2.1, how do I really know I am actually using an older version and which version that is?

I very much appreciate your help. My questions here are related to our security and license compliance process which relies on a high level of version knowledge and trace-ability with our dependencies. Since we consume a net core macro version for our runtime and SDK, but each project itself references the nuget packages directly by version, it is a challenge to know exactly what version of any given package is going to be in use.

[rbhanda]

Closing in favor of #4119