dotnet / announcements Goto Github PK
View Code? Open in Web Editor NEWSubscribe to this repo to be notified of Announcements and changes in .NET Core.
License: Creative Commons Attribution 4.0 International
Subscribe to this repo to be notified of Announcements and changes in .NET Core.
License: Creative Commons Attribution 4.0 International
Microsoft is releasing this security advisory to provide information about a vulnerability in the WCF packages for .NET Core 1.0 and 1.1, and 2.0. This advisory also provides guidance on what developers can do to update their applications correctly.
Microsoft is aware of a security vulnerability in the public versions of .NET Core where an attacker could present a certificate that is marked invalid for a specific use, but a component uses it for that purpose. This action disregards the Enhanced Key Usage tagging.
The security update addresses the vulnerability by ensuring that .NET Core components completely validate certificates.
In addition to updating any vulnerable packages and redeploying applications system administrators are advised to update their .NET Core runtimes to versions 1.0.9, 1.1.6 and 2.0.5. Developers are advised to update their .NET Core SDK to version 2.1.4 or 1.1.7. These runtime and SDK versions address CVE-2018-0764.
Please use https://github.com/dotnet/corefx/issues/26236 for discussion of this advisory.
Please use microsoft/dotnet#597 for discussion of .NET native / UWP aspects of this advisory.
The vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below
Package name | Package versions | Fixed package versions | .NET Core version |
---|---|---|---|
System.ServiceModel.Primitives | 4.4.0 | 4.4.1 | 2.0 |
System.ServiceModel.Http | 4.4.0 | 4.4.1 | 2.0 |
System.ServiceModel.NetTcp | 4.4.0 | 4.4.1 | 2.0 |
System.ServiceModel.Duplex | 4.4.0 | 4.4.1 | 2.0 |
System.ServiceModel.Security | 4.4.0 | 4.4.1 | 2.0 |
System.Private.ServiceModel | 4.4.0 | 4.4.1 | 2.0 |
Package name | Package versions | Fixed package versions | .NET Core version |
---|---|---|---|
System.ServiceModel.Primitives | 4.3.0 | 4.3.1 | 1.1 |
System.ServiceModel.Http | 4.3.0 | 4.3.1 | 1.1 |
System.ServiceModel.NetTcp | 4.3.0 | 4.3.1 | 1.1 |
System.ServiceModel.Duplex | 4.3.0 | 4.3.1 | 1.1 |
System.ServiceModel.Security | 4.3.0 | 4.3.1 | 1.1 |
System.Private.ServiceModel | 4.3.0 | 4.3.1 | 1.1 |
Package name | Package versions | Fixed package versions | .NET Core version |
---|---|---|---|
System.ServiceModel.Primitives | 4.1.0 | 4.1.1 | 1.0 |
System.ServiceModel.Http | 4.1.0 | 4.1.1 | 1.0 |
System.ServiceModel.NetTcp | 4.1.0 | 4.1.1 | 1.0 |
System.ServiceModel.Duplex | 4.0.1 | 4.0.2 | 1.0 |
System.ServiceModel.Security | 4.0.1 | 4.0.2 | 1.0 |
System.Private.ServiceModel | 4.1.0 | 4.1.1 | 1.0 |
This vulnerability also affects any .NET native applications using the following NuGet packages.
NuGet Packages | Fixed NuGet Packages |
---|---|
Microsoft.NETCore.UniversalWindowsPlatform 5.2.* (contains .NET native 1.4.*) | Microsoft.NETCore.UniversalWindowsPlatform 5.2.4 |
Microsoft.NETCore.UniversalWindowsPlatform 5.3.* (contains .NET native 1.6.*) | Microsoft.NETCore.UniversalWindowsPlatform 5.3.5 |
Microsoft.NETCore.UniversalWindowsPlatform 5.4.* (contains .NET native 1.7.*) | Microsoft.NETCore.UniversalWindowsPlatform 5.4.2 |
Microsoft.NETCore.UniversalWindowsPlatform 6.0.* (contains .NET native 2.0.*) | Microsoft.NETCore.UniversalWindowsPlatform 6.0.6 |
.NET Core and ASP.NET Core have two types of dependencies: direct and transitive. If your project has a direct or transitive dependency on any of the packages and versions listed above, you are affected.
.NET Core has two different project file formats, depending on what software created the project.
project.json
is the format used in .NET Core 1.0 and Microsoft Visual Studio 2015.csproj
is the format used in .NET Core 1.1 and Microsoft Visual Studio 2017.You must ensure you follow the correct update instructions for your project type.
Direct dependencies are dependencies where you specifically add a package to your project. For example, if you add the Microsoft.AspNetCore.Mvc
package to your project then you have taken a direct dependency on Microsoft.AspNetCore.Mvc
.
Direct dependencies are discoverable by reviewing your project.json
or csproj
file.
Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, the Microsoft.AspNetCore.Mvc
package depends on the Microsoft.AspNetCore.Mvc.Core
package (among others). If your project has a direct dependency on Microsoft.AspNetCore.Mvc
then it also has a transitive dependency on the Microsoft.AspNetCore.Mvc.Core
package.
Transitive dependencies are reviewable in the Visual Studio Solution Explorer window, which supports searching, or by reviewing the project.lock.json
file contained in the root directory of your project for project.json
projects or the project.assets.json
file contained in the obj directory of your project for csproj
projects. These files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.
You will need to fix both direct dependencies and review and fix any transitive dependencies. The affected packages and versions in the previous “Affected Software” section include each vulnerable package, the vulnerable versions, and the patched versions
Open your project.json
file in your editor. Look for the dependencies section. Below is an example dependencies section:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"System.ServiceModel.Security ": "4.0.1",
}
This example has three direct dependencies: Microsoft.NETCore.App
, Microsoft.AspNetCore.Server.Kestrel
and System.ServiceModel.Security
.
Microsoft.NetCore.App
is the platform the application targets, you should ignore this. The other packages expose their version to the right of the package name. In our example, our non-platform packages are version 1.0.1.
Review your direct dependencies for any instance of the packages and versions listed above. In the example above, there is a direct dependency on the vulnerable package, System.ServiceModel.Security
version 4.0.1.
To update to the fixed package, change the version number to be the appropriate package for your release. In the example, this would be updating System.ServiceModel.Security
to 4.0.2
After updating the vulnerable package versions, save your project.json
file.
The dependencies section in our example project.json
would now look as follows:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"System.ServiceModel.Security ": "4.0.2",
}
If you are using Visual Studio and save your updated project.json
file, Visual Studio will restore the new package version. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependency.
After you have addressed all of your direct dependencies, you must also review your transitive dependencies.
Open your projectname.csproj
file in your editor, or right click the project in Visual Studio 2017 and choose Edit projectname.csproj
from the content menu, where projectname is the name of your project. Look for PackageReference
nodes. The following shows an example project file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.ServiceModel.Security" Version="4.3.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0 " />
</ItemGroup>
</Project>
The example has a single direct dependency, as seen by the PackageReference
element. The name of the package is in the Include attribute, and the package version number is in the Version attribute that is exposed to the right of the package name. The example shows a single package System.ServiceModel.Security
version 4.3.0.
Review your PackageReference
elements for any instance of the packages and versions listed above. In the example above, there is a direct dependency on the vulnerable package, System.ServiceModel.Security
version 4.3.0.
To update to the fixed package, change the version number to the appropriate package for your release. In the example, this would be updating System.ServiceModel.Security
to 4.3.1.
After updating the vulnerable package version, save your csproj
file. The example csproj
would now look as follows:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.ServiceModel.Security" Version="4.3.1" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0 " />
</ItemGroup>
</Project>
If you are using Visual Studio and save your updated csproj
file, Visual Studio will restore the new package version. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependency.
Recompile your application.
If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to the appropriate version.
To fix this, edit the version for the expected package to be the version expected by updating your csproj
or project.json
in the same way that you used to update the vulnerable package versions.
After you have addressed all of your direct dependencies, you must also review your transitive dependencies.
There are two ways to view transitive dependencies. You can either use Visual Studio’s Solution Explorer, or you can review your project.lock.json
(project.json/VS2015) or project.assets.json
(csproj/VS2017) file.
If you want to use Visual Studio 2015, open your project in Visual Studio 2015 and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names and make a note of the version numbers of any results you find.
For example, searching for Microsoft.AspNetCore.Mvc.Core
in an example project that contains a reference to Microsoft.AspNetCore.Mvc
shows the following results in Visual Studio 2015.
The search results appear as a tree. In these results, you can see we have found references to Microsoft.AspNetCore.Mvc
, version 1.0.1, ` vulnerable version.
The first entry under the References heading refers to the target framework your application is using. This will be .NETCoreApp
, .NETStandard
or .NET-Framework-vX.Y.Z
(where X.Y.Z is an actual version number) depending on how you configured your application. Under your target framework will be the list of packages you have directly taken a dependency on. In this example, the application takes a dependency on Microsoft.AspNetCore.Mvc
. Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions. In this case the Microsoft.AspNetCore.Mvc
package takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core
and numerous other packages.
Open the project.lock.json
file in your editor. We suggest you use an editor that understands json and allows you to collapse and expand nodes to review this file; both Visual Studio and Visual Studio Code provide this functionality.
If you are using Visual Studio the project.lock.json
file is “under” the project.json
file. Click the right pointing triangle, ▷, to the left of the project.json
file to expand the solution tree to expose the project.lock.json
file. The following image shows a project with the project.json
file expanded to show the project.lock.json
file.
Search the project.lock.json
file for the vulnerable packages, using the format packagename/
, using each of the package names from the table above. If you find any vulnerable assembly name in your search examine the line on which they are found, the version number is after the /
and compare to the vulnerable versions table above. For example a search result that shows Microsoft.AspNetCore.Mvc.Cors/1.0.1
is a reference to v1.0.1 of Microsoft.AspNetCore.Mvc.Cors
. If your project.lock.json
file includes references to any of the package versions shown above then you will need to fix the transitive dependencies.
If you have not found any reference to any of the vulnerable package versions listed above this means none of your direct dependencies depend on any vulnerable packages or you have already fixed the problem by updating the direct dependencies.
If your transitive dependency review found references to any of the vulnerable packages you must add a direct dependency to the updated package to your project.json
file to override the transitive dependency. Open your project.json
and find the dependencies section. For example:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.0.0"
}
For each of the vulnerable packages your search returned you must add a direct dependency to the updated version by adding it to the project.json
file. You do this by adding a new line to the dependencies section, referring the fixed version. For example, if your search showed a transitive reference to the vulnerable System.ServiceModel.Security
version 4.0.1 you would add a reference to the appropriate fixed version, 4.0.2. Edit the project.json
file as follows:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"System.ServiceModel.Security": "4.0.2",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.0.0"
}
After you have added direct dependencies to the fixed packages, save your project.json
file.
If you are using Visual Studio save your updated project.json
file and Visual Studio will restore the new package versions. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependencies.
If you want to use Solution Explorer, open your project in Visual Studio 2017, and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names and make a note of the version numbers of any results you find.
For example, searching for Microsoft.AspNetCore.Mvc.Core
in an example project that contains a package that takes a dependency on Microsoft.AspNetCore.Mvc
shows the following results in Visual Studio 2017.
The search results appear as a tree. In these results, you can see we have found references to Microsoft.AspNetCore.Mvc.Core
version 1.1.2.
Under the Dependencies node will be a NuGet node. Under the NuGet node will be the list of packages you have directly taken a dependency on and their versions. In this example, the application takes a direct dependency on Microsoft.AspNetCore.Mvc
. Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions. In the example the Microsoft.AspNetCore.Mvc
package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer
which in turn takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core
.
Open the project.assets.json
file from your project’s obj directory in your editor. We suggest you use an editor that understands json and allows you to collapse and expand nodes to review this file; both Visual Studio and Visual Studio Code provide this functionality.
Search the project.assets.json
file for each of the vulnerable packages, using the format packagename/
using the package name from the table above. If you find the assembly name in your search examine the line on which they are found, the version number is after the /
and compare to the vulnerable versions table above. For example a search result that shows Microsoft.AspNetCore.Mvc.Cors/1.1.0
is a reference to v1.1.0 of Microsoft.AspNetCore.Mvc.Cors
. If your project.assets.json
file includes references to any of the vulnerable packages shown above then you will need to fix the transitive dependencies.
If you have not found any reference to any vulnerable packages this means none of your direct dependencies depend on any vulnerable packages or you have already fixed the problem by updating the direct dependencies.
If your transitive dependency review found references to any of the vulnerable packages you must add a direct dependency to the updated package to your csproj
file to override the transitive dependency. Open your projectname.csproj
file in your editor, or right click on the project in Visual Studio 2017 and choose Edit projectname.csproj
from the content menu, where projectname
is the name of your project. Look for PackageReference
nodes, for example:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
</ItemGroup>
</Project>
For each of the vulnerable packages your search returned you must add a direct dependency to the updated version by adding it to the csproj
file. You do this by adding a new line to the dependencies section, referring the fixed version. For example, if your search showed a transitive reference to the vulnerable System.ServiceModel.Security
, version 4.3.0 you would add a reference to the appropriate fixed version,.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.ServiceModel.Security" Version="4.3.1`" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
</ItemGroup>
After you have added the direct dependency reference, save your csproj
file.
If you are using Visual Studio, save your updated csproj
file and Visual Studio will restore the new package versions. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependencies.
Finally rebuild your application, test as you would do normally and redeploy using your favored deployment mechanism.
.NET native requires that applications be re-processed by the .NET native compiler to incorporate the fixes and the re-processed version needs to be distributed via the Windows Store.
We recommend that you update your .NET UWP apps to use the latest minor version of the Microsoft.NETCore.UniversalWindowsPlatform
NuGet package so that you can build and verify that your app works as expected when updated. If you are using version 6.0.x, you should update to 6.0.6 and if you’re using 5.2.x, you can update to 5.2.4. Of course, you can update to a higher major version too, but we are distributing security updates for all impacted major versions (currently 5.2.x, 5.3.x, 5.4.x and 6.0.x). Additionally, whether or not you update your NuGet packages, all applications submitted to the store after today will be automatically fixed during submission processing.
If you do not update your app in the Store, it will automatically be reprocessed and distributed via an application update in the next few weeks. Users who have automatic app updates enabled will get the fix with no intervention on your or their parts. Because updated apps are distributed through the Windows Store, sideloaded apps will not be automatically updated. We recommend that developers who distribute sideloaded apps update the affected NuGet packages, rebuild their applications and distribute them to their users.
Microsoft is committed to keeping UWP applications secure and to supporting developers. If you have feedback on the fix distribution process, please let us know at [email protected].
If you have found a potential security issue in .NET Core, please email details to [email protected]. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including Terms and Conditions are at https://aka.ms/corebounty.
You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue where you can ask questions.
An application can be pinned to a previous version of the runtime by editing the application.runtime.config file for that application and editing the framework version and setting rollForward
to false
. This should be treated as a temporary measure and the application updated to work with the patched versions of the framework.
Note that this file is optional, you may need to create it for each application alongside the executable.
V2.0 (Jan 29, 2018): Advisory updated with correct package versions and update instructions.
V1.0 (Jan 9, 2018): Advisory published.
Version 2.0
Last Updated 2018-01-29
Today we announce the availability of .NET Core 2.0.0 Preview .
Please use dotnet/core #711 for discussion and questions.
Update: Alpine is now supported with .NET Core 2.1.
An Alpine-based Docker image is now available for .NET Core. Alpine is much smaller than Debian, which we have used for the .NET Core base image to date. There have been many requests for an Alpine image. We are pleased to make it available. Please check out .NET Core Docker Sample to see examples of using this image.
We have added two new images:
2.1-runtime-alpine
2.1-runtime-deps-alpine
Alpine support is part of the .NET Core 2.1 release. .NET Core 2.1 images are currently provided at the microsoft/dotnet repo, including the new Alpine images.
Please share your thoughts on this change and see what others are saying at:
The primary goal of Alpine is very small deployments. We have been considering various design decisions to make .NET Core Alpine base images as small as possible to align with that. In this first iteration, we enabled .NET Core 2.0 Globalization Invariant Mode in order to reduce the default size of the image. This change reduced the image by ~30MB. You can see the reduction in size for .NET Core images relative to Debian in the following table.
2.1 Image | Debian | Alpine |
---|---|---|
-deps |
153MB (68MB compressed) | 13.8 MB (6MB compressed) |
-runtime |
222MB (96MB compressed) | 82.5 (34MB compressed) |
Note: The compressed size is what you will see in a registry and is the wire-size cost.
We are also considering saving more space by native-compiling fewer assemblies. .NET Core runtime assemblies are native-compiled with the crossgen tool in the Ready2Run format. Native-compiled code delivers superior startup performance but at the cost of 2-3x larger files. We have the opportunity to compile less, skipping compiling assemblies in part or in whole. We believe that we can save at least another 10MB through compiling less without a material drop in performance. For scenarios that value size over startup or where wire cost is significant, it may be valuable to aggressively reduce the number/% of compilation.
Alpine images are only available for .NET Core 2.1. At the current time, only Runtime images are available. We intend to offer SDK images at a later date.
Use cases that cannot tolerate Globalization invariant mode can reset the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT
environment variable and install the ICU package. Please check out .NET Core Docker Sample to see examples of using this image with and without Globalization Invariant Mode enabled.
Please test your workloads with the new Alpine image. In particular, we want to know if enabling .NET Core Globalization Invariant Mode is acceptable/appreciated.
.NET Core 2.1 has been adding platform intrinsic APIs to support directly calling processor specific instructions, such as Intel’s x86 SIMD instructions. See the initial platform intrinsics design for more information.
We have decided that it makes the most sense for this intrinsics feature to ship in a “preview” status in the .NET Core 2.1 RTM timeframe. This means that the runtime support we are implementing will be included, but the assembly exposing the intrinsics will only be available to projects via explicit reference to a “preview-only” package. These APIs won’t be included in the official .NET Core 2.1 packages.
Given our limited time and resources, recent changes in the approach we take to expose the intrinsics, and API changes prompted by design feedback from the community, we don’t believe there is enough time to settle these APIs for 2.1. We plan to follow the pattern of other recent features like Span and Memory that first shipped in preview before formally joining the supported API surface. Not only would we expect the next version of .NET Core to support more intrinsics than could be supported in 2.1, but we expect to have real usage examples in CoreFX and higher level components as well. These real world examples, as well as feedback from customers who opt in to the preview, should give us the confidence we need to officially support the APIs going forward.
Please share your thoughts on this change and see what others are saying at:
https://github.com/dotnet/corefx/issues/27486
In the coming days, we plan on removing System.Runtime.Intrinsics.dll from the Microsoft.NETCore.App package. This means any libraries/applications that are using these APIs will no longer compile by default, and will not run on new builds of .NET Core 2.1.
At the same time, we will start producing a new System.Runtime.Intrinsics.Experimental NuGet package. In order to continue using these APIs on .NET Core 2.1, a project will need to add a reference to this new package.
As its name implies, this package is experimental and should only be used for preview purposes. It isn’t expected to be used in production scenarios. Future version of .NET Core (after 2.1) will be allowed to break this package. This enables us respond to future feedback that requires the APIs to be modified.
In the future, when we are confident we have the intrinsic APIs right, we will stop producing the System.Runtime.Intrinsics.Experimental package. The platform intrinsics APIs will then be added back to Microsoft.NETCore.App and will be officially supported.
.NET Core is supported on a range of operating systems and versions. Each platform has distinct Lifecycles defined by the parent organization. .NET Core support will take these Lifecycle schedules into account when adding or removing versions from the supported list.
.NET Core supports a set of operating systems. When a new .NET Core version is released, it will typically support the latest version of each operating system, for example Fedora 26. If a new operating system version is released afterwards, for example Fedora 27, it will typically be supported when the next .NET Core version is released.
'Support' means that .NET Core is built and tested on the OS, security and other updates will be made available and Microsoft Developer Support may be contacted for assistance with .NET Core on the environment.
To discuss the .NET Core OS version support policy, see dotnet/core#798
Microsoft is releasing this security advisory to provide information about a vulnerability in the public versions of .NET Core 1.0 and 1.1, and 2.0. This advisory also provides guidance on what developers can do to update their applications correctly.
Microsoft is aware of a security vulnerability in the public version of .NET Core where a malformed certificate or other ASN.1 formatted data could lead to a denial of service via an infinite loop on Linux and macOS.
System administrators are advised to update their .NET Core runtimes to versions 1.0.8, 1.1.5 and 2.0.3. Developers are advised to update their .NET Core SDK to version 2.0.3 or 1.1.5.
Please use https://github.com/dotnet/corefx/issues/25245 for discussion of this advisory.
.NET Core applications running on Windows are not affected by this vulnerability.
The vulnerabilities affect any Microsoft .NET Core project if it uses any of affected runtime versions listed below and is running on Linux.
Platform | Runtime Version | Fixed runtime version |
---|---|---|
Linux | 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.7 1.1.0, 1.1.1, 1.1.2, 1.1.4 2.0.0 |
1.0.8 1.1.5 2.0.3 |
macOS | 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.7 1.1.0, 1.1.1, 1.1.2, 1.1.4 |
1.0.8 1.1.5 |
Any application running against .NET Core 1.0.7 or lower, or 1.1.2 or lower, or 2.0.0 is affected. The default version of the .NET core runtime can be listed by running dotnet --info
, which should produce output in the form of
.NET Command Line Tools (2.0.2)
Product Information:
Version: 2.0.2
Commit SHA-1 hash: a04b4bf512
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.2\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
As this only displays the latest version of the runtime installed it may hide the fact that you have a vulnerable runtime. A complete list of runtimes can be discovered by performing a directory listing in the install root directories. By default these are
Operating System | Location |
---|---|
macOS | /usr/local/share/dotnet/shared/Microsoft.NETCore.App/ |
Supported Linux platforms | /usr/share/dotnet/shared/Microsoft.NETCore.App/ |
Each runtime version is installed in its own directory, where the directory name is the version number. If you do not have a directory for 1.0.8, 1.1.5 or 2.0.3 then any applications targeting .NET Core will be vulnerable.
Applications can be fixed by installing the latest runtimes or SDKs. Typically application servers only install a runtime package, developer machines install SDKs. Installers for the runtimes can be downloaded from the Runtime and SDK download archive. Version 1.1.5 will also install version 1.0.8 of the runtime.
If you have built a self-contained application you must install the new runtime and SDK, recompile your application and redeploy.
If you have found a potential security issue in .NET Core, please email details to [email protected]. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including Terms and Conditions are at https://aka.ms/corebounty.
You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue where you can ask questions.
An application can be pinned to a previous version of the runtime by editing the application.runtime.config file for that application and editing the framework version and setting rollForward
to false
. This should be treated as a temporary measure and the application updated to work with the patched versions of the framework.
Note that this file is optional, you may need to create it for each application alongside the executable.
Thanks to Bachraty Gergely for reporting this issue.
V1.0 (Nov 14, 2017): Advisory published.
V1.1 (Nov 14, 2017): Link to CVE corrected.
V1.2 (Nov 14, 2017): Version numbers updated to reflect the correct version, 2.0.3
Version 1.2
Last Updated 2017-11-15
A change in the version number strategy for .NET Core SDK resulted in some nightly builds having a higher version number. This higher version number will block the installation of the correct .NET Core SDK.
If you have installed nightly builds of the .NET Core SDK that start with version number that begin with 2.2.0-preview1
or 15.5.0-preview
, you must manually uninstall these preview builds before later versions of the SDK with version numbers like 2.1.xxx will be available. This may have occurred by installing nightly builds of the .NET Core SDK or concurrent nightly builds of Visual Studio previews.
Please share your thoughts on this change and see what others are saying at:
We changed the version number strategy for .NET Core SDK as development was ongoing. Because of this, version numbers on the old scheme appeared in nightly builds. Unfortunately, these numbers are higher than the version numbers in the new scheme. All of the newer SDKs for .NET Core 2.1 will be ignored due to this higher version number; this includes newer nightly builds, public previews and eventual releases.
These older version numbers are similar to the following, with the last several different values in the last six digits:
2.2.0-preview1-008000
15.5.0-preview-007082
Since the newer versions are in the form:
2.1.300-preview1-008000
If you have installed nightly builds, please uninstall any .NET SDK versions that start with 2.2.0-preview1
or 15.5.0-preview
.
The .NET Core team has been working on a linker in collaboration with the Mono team. It is based on the Mono Linker project, and by extension, on the Cecil project.
The goal of the .NET IL Linker project is two part:
You can start using the linker today, using the following instructions:
Please share your thoughts on this change and see what others are saying at:
In trivial cases, the linker can reduce the size of applications by 50%. The size wins may be more favorable or more moderate for larger applications. The linker removes code in your application and dependent libraries that are not reached by any code paths. It is effectively an application-specific dead code analysis.
The IL Linker currently only supports .NET Core Self Contained Applications with this first preview version. You can try using the linker with an example self-contained .NET Core application sample. The primary difference with this application is that it has a reference to the ILLink.Tasks package in its cspoj project file.
The Linker provides an option to print a size improvement chart that describes binaries that have been removed from an application or that have been reduced in size. It also provides the total % size reduction for the application. You can see an example of one of these charts in the following example.
Please provide feedback on your use of the linker. We are actively looking for feedback to improve the linker. In particular, we are looking for feedback on the following topics:
Please create issue with your feedback at either mono/linker or dotnet/core. Also feel free to contact the team at [email protected].
And, it wouldn't be right to announce this linker without a hat tip to Joel Spolsky who we can give the honorary and historical distinction of feature requestor.
The .NET Core SDK (CLI) is being updated to version 1.1.0 in Visual Studio 2017 15.3. The changes, which are listed in the SDK release notes are in support of Visual Studio 2017. 1.1.0 Preview 1 is available for download and the previously released Runtime-only installers and binaries can be found on the .NET Core 1.0.5 and 1.1.2 installer pages.
Discussions for this release should be posted in the .NET Core SDK repo.
The following Security and Quality Updates were released this month. Known issues are also listed.
Known Issue
The .NET Framework February 2018 Preview of Quality Rollup was released on February 20th and then pulled for Windows 7 SP1, Windows Server 2008 R2 SP1, and Windows Server 2008 SP2 due an an issue found in System.Security.Cryptography.Xml
. Please uninstall the rollup if you installed it on one of those Windows versions. See the following for more information: Exceptions in System.Security.Cryptography.Xml.Reference.LoadXml after you install the February 2018 .NET Framework Preview of Quality Rollup updates for Windows 7 SP1, Server 2008 R2 SP1, and Server 2008 SP2.
.NET Core and .NET Framework Windows container images have been updated to use a new tag naming scheme for Windows container images, for both Windows Server Version 1709 and Windows Server 2016.
You will see the following changes in .NET Docker repos:
The following tags are examples of the new tag scheme:
This scheme is in use in the following repos:
Please share your thoughts on this change and see what others are saying at:
With the release of Windows Server 1709, Windows Server container images adopted stable tags, in addition to the release-specific tags already in use.
The following stable base tags are used in Windows repos, microsoft/nanoserver and microsoft/windowsservercore:
ltsc2016
sac2016
1709
1709
Notes: The 1709 release is a Semi Annual Channel release, but is missing the sac
prefix. Windows Server 2016 Server Core is a Long Term Support Channel release.
Release-specific tags will still be used in Windows repos, which will look like the following examples:
10.0.14393.1770
1709_KB4043961
The following stable base tags will be used in .NET repos:
windowsservercore-ltsc2016
nanoserver-sac2016
windowsservercore-1709
nanoserver-1709
The following tags are examples of the new tag scheme:
This scheme is in use in the following repos:
In cases that an immutable Docker reference is required, you are recommended to use an image digest instead of a tag name. Using an image digest will ensure that docker pull and build always use the same image, even after tags are updated.
The following string is an example of a digest reference:
microsoft/dotnet-framework@sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e
You can use this string as a parameter to docker pull
or docker run
. You can also use it with a FROM line to ensure that docker build
is consistent, such as with the following.
FROM microsoft/dotnet-framework@sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e
You can determine an image digest with various Docker commands.
Image digests are displayed with every pull.
C:\>docker pull microsoft/dotnet-framework:4.7.1-windowsservercore-1709
4.7.1-windowsservercore-1709: Pulling from microsoft/dotnet-framework
Digest: sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e
Status: Image is up to date for microsoft/dotnet-framework:4.7.1-windowsservercore-1709
Image digests are displayed for images with the --digests
parameter.
$ docker images --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
microsoft/dotnet 2.0-runtime sha256:2e9ae1f83873ffb897f8fb7ada205b67b675a1b2c014d5875a49c050783cc469 c73382e1bbf7 38 hours ago 219MB
Image digests are displayed as part of docker inspect
.
$ docker inspect microsoft/dotnet:2.0-runtime -f '{{.RepoDigests}}'
[microsoft/dotnet@sha256:2e9ae1f83873ffb897f8fb7ada205b67b675a1b2c014d5875a49c050783cc469]
We recommend that you use stable tags during development and image digests for production. This approach gives you an opportunity to test any image updates before they affect production apps. .NET images are updated each month with security updates. We recommend that you rebuild your images each month with these updates to ensure that applications are secure. You need to re-pull base images in order to update them. Otherwise, docker build
is happy to use stale local copies of base images.
If you are not able to update source Dockerfiles regularly, then it may make more sense to reference stable tags. You still need to rebuild and redeploy your images in order to update your applications in production.
As part of the .NET Core 2.0 release, .NET Core cryptography APIs were changed to use the Apple Security Framework when running on macOS (10.12 and later versions). .NET Core 1.x uses OpenSSL on macOS/OS X (10.11 and later versions).
There were two challenges with using OpenSSL on macOS that motivated this change:
.NET Core now uses the cryptography API that is offered for each operating system:
All cryptography functionality is now provided by the Apple Security Framework. Only types whose name includes "OpenSsl", such as RSAOpenSsl, will continue to use OpenSSL on macOS. When using these APIs, OpenSSL needs to be installed separately via Homebrew since .NET Core doesn't install it.
The following types now use the Apple Security framework:
There are some cryptography operations that were supported by OpenSSL on macOS that are no longer supported with the new implementation, due to the functionality provided by the Apple Security Framework. See the Cross-Platform Cryptography document to learn about cryptography support per operating system.
The following types/scenarios have been affected by this change:
Microsoft is releasing this security advisory to provide information about vulnerabilities in public .NET Core and ASP.NET Core. This advisory also provides guidance on what developers can do to update their applications correctly.
.NET Core & ASP.NET Core are the next generation of .NET that provide a familiar and modern framework for web and cloud scenarios. These products are actively developed by the .NET and ASP.NET team in collaboration with a community of open source developers, running on Windows, Mac OS X and Linux. When .NET Core was released, the version number was reset to 1.0.0 to reflect the fact that it is a separate product from its predecessor -.NET.
To discuss the ASP.NET Core issues please see https://github.com/aspnet/Mvc/issues/6246
To discuss the CoreFX Core issues please see https://github.com/dotnet/corefx/issues/19535
CVE | Description |
---|---|
CVE-2017-0248 | Security Feature Bypass |
CVE-2017-0247 | Denial of Service |
CVE-2017-0249 | Elevation of Privilege |
CVE-2017-0256 | Spoofing |
The vulnerabilities affect any Microsoft .NET Core project if it uses the following affected package versions.
Package name | Package versions | Fixed package versions |
---|---|---|
System.Text.Encodings.Web | 4.0.0 4.3.0 |
4.0.1 4.3.1 |
System.Net.Http | 4.1.1 4.3.1 |
4.1.2 4.3.2 |
System.Net.Http.WinHttpHandler | 4.0.1 4.3.0 |
4.0.2 4.3.1 |
System.Net.Security | 4.0.0 4.3.0 |
4.0.1 4.3.1 |
System.Net.WebSockets.Client | 4.0.0 4.3.0 |
4.0.1 4.3.1 |
Microsoft.AspNetCore.Mvc | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Core | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Abstractions | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.ApiExplorer | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Cors | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.DataAnnotations | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Formatters.Json | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Formatters.Xml | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Localization | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Razor.Host | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.Razor | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.TagHelpers | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.ViewFeatures | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
Microsoft.AspNetCore.Mvc.WebApiCompatShim | 1.0.0, 1.0.1, 1.0.2, 1.0.3 1.1.0, 1.1.1, 1.1.2 |
1.0.4 1.1.3 |
.NET Core and ASP.NET Core have two types of dependencies: direct and transitive. If your project has a direct or transitive dependency on any of the packages and versions listed above, you are affected.
Note: As part of patching ASP.NET Core MVC we update every Microsoft.AspNetCore.Mvc.* package. If, for example, you have a dependency on Microsoft.AspNetCore.Mvc
you should update to the appropriate version first (1.0.x should be updated to 1.0.4, 1.1.x should be updated to 1.1.3), and it will also update any other vulnerable Microsoft.AspNetCore.Mvc
dependency.
.NET Core has two different project file formats, depending on what software created the project.
project.json
is the format used in .NET Core 1.0 and Microsoft Visual Studio 2015.csproj
is the format used in .NET Core 1.1 and Microsoft Visual Studio 2017.You must ensure you follow the correct update instructions for your project type.
Direct dependencies are dependencies where you specifically add a package to your project. For example, if you add the Microsoft.AspNetCore.Mvc
package to your project then you have taken a direct dependency on Microsoft.AspNetCore.Mvc
.
Direct dependencies are discoverable by reviewing your project.json
or csproj
file.
Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, if you add the Microsoft.AspNetCore.Mvc
package to your project it depends on the Microsoft.AspNetCore.Mvc.Core
package (among others). Your project has a direct dependency on Microsoft.AspNetCore.Mvc
and a transitive dependency on the Microsoft.AspNetCore.Mvc.Core
package.
Transitive dependencies are reviewable in the Visual Studio Solution Explorer window, which supports searching, or by reviewing the project.lock.json
file contained in the root directory of your project for project.json
projects or the project.assets.json
file contained in the obj directory of your project for csproj
projects. These files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.
You will need to fix both direct dependencies and review and fix any transitive dependencies. The affected packages and versions in the previous “Affected Software” section include each vulnerable package, the vulnerable versions, and the patched versions
Note: If you are using ASP.NET Core MVC in your projects you should first update the Microsoft.AspNetCore.Mvc
version according to the affected versions table above. If you are currently using version 1.0.0, 1.0.1, 1.0.2 or 1.0.3 you should update your package version to 1.0.4. If you are using version 1.1.0, 1.1.1 or 1.1.2 you should update your package version to 1.1.3. This will update every MVC package to the fixed versions.
Open your project.json
file in your editor. Look for the dependencies section. Below is an example dependencies section:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"Microsoft.AspNetCore.Mvc ": "1.0.1",
}
This example has three direct dependencies: Microsoft.NETCore.App
, Microsoft.AspNetCore.Server.Kestrel
and Microsoft.AspNetCore.Mvc
.
Microsoft.NetCore.App
is the platform the application targets, you should ignore this. The other packages expose their version to the right of the package name. In our example, our non-platform packages are version 1.0.1.
Review your direct dependencies for any instance of the packages and versions listed above. In the example above, there is a direct dependency on one of the vulnerable packages, Microsoft.AspNetCore.Mvc
version 1.0.1.
To update to the fixed package, change the version number to be the appropriate package for your release. In the example, this would be updating Microsoft.AspNetCore.Mvc
to 1.0.4.
After updating the vulnerable package versions, save your project.json
file.
The dependencies section in our example project.json
would now look as follows:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"Microsoft.AspNetCore.Mvc": "1.0.4",
}
If you are using Visual Studio and save your updated project.json
file, Visual Studio will restore the new package version. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependency.
After you have addressed all of your direct dependencies, you must also review your transitive dependencies.
Open your projectname.csproj
file in your editor, or right click the project in Visual Studio 2017 and choose Edit projectname.csproj
from the content menu, where projectname is the name of your project. Look for PackageReference
nodes. The following shows an example project file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0 " />
</ItemGroup>
</Project>
The example has two direct package dependencies, as seen by the two PackageReference
elements. The name of the package is in the Include attribute, and the package version number is in the Version attribute that is exposed to the right of the package name. The example shows two packages Microsoft.AspNetCore
version 1.1.1, and Microsoft.AspNetCore.Mvc.Core
version 1.1.2.
Review your PackageReference
elements for any instance of the packages and versions listed above. In the example above, there is a direct dependency on one of the vulnerable packages, Microsoft.AspNetCore.Mvc
version 1.1.2.
To update to the fixed package, change the version number to the appropriate package for your release. In the example, this would be updating Microsoft.AspNetCore.Mvc
to 1.1.3.
After updating the vulnerable package version, save your csproj
file. The example csproj
would now look as follows:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.3" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0 " />
</ItemGroup>
</Project>
If you are using Visual Studio and save your updated csproj
file, Visual Studio will restore the new package version. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependency.
Recompile your application.
If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to the appropriate version.
For example if your project refers to Microsoft.AspNetCore.Routing
with a version number of 1.0.1 when you update your Microsoft.AspNetCore.Mvc
package to 1.0.4, compilation will throw:
NU1012 Dependency conflict. Microsoft.AspNetCore.Mvc.Core 1.0.4 expected Microsoft.AspNetCore.Routing >= 1.0.4 but received 1.0.1
To fix this, edit the version for the expected package to be the version expected by updating your csproj
or project.json
in the same way that you used to update the vulnerable package versions.
After you have addressed all of your direct dependencies, you must also review your transitive dependencies.
There are two ways to view transitive dependencies. You can either use Visual Studio’s Solution Explorer, or you can review your project.lock.json
(project.json/VS2015) or project.assets.json
(csproj/VS2017) file.
If you want to use Visual Studio 2015, open your project in Visual Studio 2015 and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names and make a note of the version numbers of any results you find.
For example, searching for Microsoft.AspNetCore.Mvc.Core
in an example project that contains a reference to Microsoft.AspNetCore.Mvc
shows the following results in Visual Studio 2015.
The search results appear as a tree. In these results, you can see we have found references to Microsoft.AspNetCore.Mvc
, version 1.0.1, ` vulnerable version.
The first entry under the References heading refers to the target framework your application is using. This will be .NETCoreApp
, .NETStandard
or .NET-Framework-vX.Y.Z
(where X.Y.Z is an actual version number) depending on how you configured your application. Under your target framework will be the list of packages you have directly taken a dependency on. In this example, the application takes a dependency on Microsoft.AspNetCore.Mvc
. Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions. In this case the Microsoft.AspNetCore.Mvc
package takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core
and numerous other packages.
Open the project.lock.json
file in your editor. We suggest you use an editor that understands json and allows you to collapse and expand nodes to review this file; both Visual Studio and Visual Studio Code provide this functionality.
If you are using Visual Studio the project.lock.json
file is “under” the project.json
file. Click the right pointing triangle, ▷, to the left of the project.json
file to expand the solution tree to expose the project.lock.json
file. The following image shows a project with the project.json
file expanded to show the project.lock.json
file.
Search the project.lock.json
file for each of the vulnerable packages, using the format AssemblyName/
. If you find any vulnerable assembly name in your search examine the line on which they are found, the version number is after the /
and compare to the vulnerable versions table above. For example a search result that shows Microsoft.AspNetCore.Mvc.Core/1.0.1
is a reference to v1.0.1 of Microsoft.AspNetCore.Mvc.Core
. If your project.lock.json
file includes references to any of the vulnerable packages shown above then you will need to fix the transitive dependencies.
If you have not found any reference to any vulnerable packages this means none of your direct dependencies depend on any vulnerable packages or you have already fixed the problem by updating the direct dependencies.
If your transitive dependency review found references to any of the vulnerable packages you must add a direct dependency to the updated package to your project.json
file to override the transitive dependency. Open your project.json
and find the dependencies section. For example:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0"
}
For each of the vulnerable packages your search returned you must add a direct dependency to the updated version by adding it to the project.json
file. You do this by adding a new line to the dependencies section, referring the fixed version. For example, if your search showed a transitive reference to the vulnerable System.Net.Security
version 4.0.0 you would add a reference to the appropriate fixed version, 4.0.1. Edit the project.json
file as follows:
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"System.Net.Security": "4.0.1",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.1"
}
After you have added direct dependencies to the fixed packages, save your project.json
file.
If you are using Visual Studio save your updated project.json
file and Visual Studio will restore the new package versions. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependencies.
If you want to use Solution Explorer, open your project in Visual Studio 2017, and then press Ctrl+; to activate the search in Solution Explorer. Search for each of the vulnerable package names and make a note of the version numbers of any results you find.
For example, searching for Microsoft.AspNetCore.Mvc.Core
in an example project that contains a package that takes a dependency on Microsoft.AspNetCore.Mvc
shows the following results in Visual Studio 2017.
The search results appear as a tree. In these results, you can see we have found references to Microsoft.AspNetCore.Mvc.Core
version 1.1.2.
Under the Dependencies node will be a NuGet node. Under the NuGet node will be the list of packages you have directly taken a dependency on and their versions. In this example, the application takes a direct dependency on Microsoft.AspNetCore.Mvc
. Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions. In the example the Microsoft.AspNetCore.Mvc
package takes a dependency on a version of Microsoft.AspNetCore.Mvc.ApiExplorer
which in turn takes a dependency on a vulnerable version of Microsoft.AspNetCore.Mvc.Core
.
Open the project.assets.json
file from your project’s obj directory in your editor. We suggest you use an editor that understands json and allows you to collapse and expand nodes to review this file; both Visual Studio and Visual Studio Code provide this functionality.
Search the project.assets.json
file for each of the vulnerable packages, using the format AssemblyName/
. If you find any vulnerable assembly name in your search examine the line on which they are found, the version number is after the /
and compare to the vulnerable versions table above. For example a search result that shows Microsoft.AspNetCore.Mvc.Core/1.1.0
is a reference to v1.1.0 of Microsoft.AspNetCore.Mvc.Core
. If your project.assets.json
file includes references to any of the vulnerable packages shown above then you will need to fix the transitive dependencies.
If you have not found any reference to any vulnerable packages this means none of your direct dependencies depend on any vulnerable packages or you have already fixed the problem by updating the direct dependencies.
If your transitive dependency review found references to any of the vulnerable packages you must add a direct dependency to the updated package to your csproj
file to override the transitive dependency. Open your projectname.csproj
file in your editor, or right click on the project in Visual Studio 2017 and choose Edit projectname.csproj
from the content menu, where projectname
is the name of your project. Look for PackageReference
nodes, for example:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
</ItemGroup>
</Project>
For each of the vulnerable packages your search returned you must add a direct dependency to the updated version by adding it to the csproj
file. You do this by adding a new line to the dependencies section, referring the fixed version. For example, if your search showed a transitive reference to the vulnerable System.Net.Security
version 4.3.0 you would add a reference to the appropriate fixed version, 4.3.1.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Net.Security" Version="4.3.1" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
</ItemGroup>
After you have added the direct dependency reference, save your csproj
file.
If you are using Visual Studio, save your updated csproj
file and Visual Studio will restore the new package versions. You can see the restore results by opening the Output Window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you are not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore
command to restore your new dependencies.
Finally rebuild your application, test as you would do normally and redeploy using your favored deployment mechanism.
If you have found a potential security issue in .NET Core, please email details to [email protected]. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including Terms and Conditions are at https://aka.ms/corebounty.
You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue where you can ask questions.
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
Microsoft thanks the following for working with us to help protect customers:
Sorry guys
ref: #40
Referencing #29.
Will it be possible to :
a) Provide ARM32 builds for the SDK at its current state
or
b) Provide links on how to build the .Net Core SDK for ARM32?
The thing is I am planning to use it in a virtual environnement, through proot + qemu-arm-static. This way I would be able to build and, more importantly, run unit tests on ARM32. Another thing I am planning to do is to setup a build environnement on i686 through virtualisation as qemu doesn't seem to be able to emulate x86_64 on i686 (but arm32 does seem to work well enough).
Thank you in advance.
Sergio
The RyuJIT JIT compiler will be used for all platform combinations for .NET Core 2.0 and beyond. JIT32 will be removed from the product. For .NET Core 1.x, RyuJIT is used for x64 and JIT32 is used for x86 chip support.
We intend for RyuJIT to be a 100% functionally compatible replacement for JIT32. RyuJIT has gone through extensive stress testing. This brings the .NET Core 32-bit product behavior much closer to the 64-bit product behavior.
We will publish more information on this change later. For now, this is just the announcement.
Note: Windows is the only supported 32-bit platform for .NET Core 1.x and 2.x.
Open Source - RyuJIT is open source. JIT32 is not open source.
Single JIT Codebase - There is now a single codebase for the CoreCLR JIT. This helps everyone who is working on platform expansion and who is investing in JIT improvements. An example is Samsung, who is investing in Linux x86 with RyuJIT x86.
Performance - RyuJIT generally takes longer to compile than JIT32, but its optimizer can generate faster code. The performance difference may not be significant, depending on the application. In initial testing with ASP.NET, we found that the difference didn't matter. Please help us make RyuJIT faster! We will continue investing in RyuJIT performance (which often helps all architectures). If you notice performance regressions, we’re very interested to hear your results. Please contact us.
Features! - RyuJIT has more features than JIT32. The feature gap with JIT32 will grow over time. The following features are now available to x86 workloads (due to this change):
Possible compatibility concerns:
Please test! If an x86 program was working in 1.x, and failing in 2.x, please report it on GitHub or at [email protected].
Please see some of our past blog posts on RyuJIT to learn more about it.
RyuJIT is the current and future platform of JIT compilation for .NET. We will use it for all platform combinations going forward. We're more efficient as a developer community if we have a single codebase to learn, work on and improve.
Microsoft is releasing this security advisory to provide information about a vulnerability in the public versions of .NET Core 1.0 and 1.1, and 2.0. This advisory also provides guidance on what developers can do to update their applications correctly.
Microsoft is aware of a Denial of Service vulnerability in all public versions of .NET core due to improper processing of XML documents. An attacker who successfully exploited this vulnerability could cause a denial of service against a .NET application. A remote unauthenticated attacker could exploit this vulnerability by issuing specially crafted requests to a .NET Core application.
The update addresses the vulnerability by correcting how .NET core handles XML document processing.
System administrators are advised to update their .NET Core runtimes to versions 1.0.9, 1.1.6 and 2.0.5. Developers are advised to update their .NET Core SDK to version 2.1.4 or 1.1.7. These runtime and SDK versions will also address CVE-2018-0786.
Please use https://github.com/dotnet/corefx/issues/26237 for discussion of this advisory.
The vulnerability affects any Microsoft .NET Core project if it uses any of affected runtime versions listed below
Runtime Version | Fixed runtime version |
---|---|
1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.7, 1.0.8 | 1.0.9 |
1.1.0, 1.1.1, 1.1.2, 1.1.4, 1.1.5 | 1.1.6 |
2.0.0, 2.0.3, 2.0.4 | 2.0.5 |
To check the runtimes installed on a computer you must view the contents of the runtime folder. By default these are
Operating System | Location |
---|---|
Windows | C:\Program Files\dotnet\shared\Microsoft.NETCore.App\ |
macOS | /usr/local/share/dotnet/shared/Microsoft.NETCore.App/ |
Supported Linux platforms | /usr/share/dotnet/shared/Microsoft.NETCore.App/ |
Each runtime version is installed in its own directory, where the directory name is the version number. If you do not have a directory for 1.0.9, 1.1.6 or 2.0.2 then any applications targeting .NET Core will be vulnerable. Downloads for all supported platforms can be acquired from https://www.microsoft.com/net/download/
Applications can be fixed by installing the latest runtimes or SDKs. Typically application servers only install a runtime package, developer machines install SDKs. Installers can be downloaded from the Runtime and SDK download archive. Runtime version 1.1.6 will also install runtime version 1.0.9.
If you have built a self-contained application you must install the new runtime and SDK, recompile your application and redeploy.
If you have found a potential security issue in .NET Core, please email details to [email protected]. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including Terms and Conditions are at https://aka.ms/corebounty.
You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue where you can ask questions.
An application can be pinned to a previous version of the runtime by editing the application.runtime.config file for that application and editing the framework version and setting rollForward
to false
. This should be treated as a temporary measure and the application updated to work with the patched versions of the framework.
Note that this file is optional, you may need to create it for each application alongside the executable.
V1.0 (Jan 9, 2018): Advisory published.
Version 1.0
Last Updated 2018-01-09
This issue has been reserved for a potential future security announcement.
This does not mean a security advisory is coming soon, it simply gives us the ability to predict the issue number that will be used in the future.
.NET Framework 4.7.1 will have built-in support for .NET Standard 2.0. This means that you don't have to deploy any additional files or use binding redirects to use .NET Standard 2.0 libraries.
For a demo, check out this video.
While libraries targeting .NET Standard 2.0 can be consumed by applications and libraries targeting .NET Framework 4.6.1 and higher, not all files that are required for .NET Standard libraries were part of .NET Framework 4.6.1. In fact, .NET Framework 4.6.1 was shipped before .NET Standard 2.0 was even designed. That's why building an application targeting .NET Framework 4.6.1 (as well as 4.6.2 and 4.7) will have to deploy additional files.
If you use Visual Studio 2017 15.3 or higher, these files are automatically copied to the application's output folder.
If you use Visual Studio 2015 and use NuGet 3.6, we'll prompt you to install a support package which will handle copying the files to the output directory.
Starting with .NET Framework 4.7.1 these files no longer have to be deployed with the application -- they are built right into the .NET Framework itself.
.NET Framework 4.7.1 also adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7.
This also removes the need for binding redirects when using .NET Standard libraries on .NET Framework because the CLR automatically unifies version numbers of assemblies that are part of the platform.
For a discussion, please go to dotnet/standard#514.
.NET Core 1.x and 2.0 do not currently support macOS High Sierra (version 10.13, currently in beta) due to changes in macOS. The .NET Core team has been testing macOS High Sierra builds and has filed bugs with Apple so that the two products can work better together.
We intend to have both .NET Core 1.x and 2.0 supporting macOS High Sierra by the time Apple ships the final production release. We are hoping to ship .NET Core 2.0 RTW with High Sierra support.
As .NET Core support for macOS High Sierra is improved, this announcement will be updated with the new status.
.NET Core does not work on macOS High Sierra.
We have reported the following issues to Apple as part of supporting .NET Core on macOS High Sierra.
Note: The issue links can only be accessed by Apple employees.
33275095 SSL Failure: macOS 10.13 (17A291j) SecureTransport in server mode can select ciphersuites not applicable to the TLS version.
.NET Core Note: When hosting an SslStream limited to TLS 1.0 or TLS 1.1 clients other than Apple SecureTransport may fail to connect.
33143630 macOS 10.13 (17A291j) SecTrustExecute fails with no error building revocation-enabled chain against a self-issued certificate.
.NET Core Note: In this situation an Apple-specific derived type of CryptographicException will be thrown with a message of “No error”.
33294006 macOS 10.13 (17A291j) libcurl changing to LibreSSL changes thread-safety model from safe to unsafe
.NET Core Note: A functioning workaround is in place, but it may regress performance for parallel HTTP requests (to avoid crashes caused by the loss of thread safety).
32948209 CCCryptorReset returns kCCUnimplemented for ECB on 10.13.
.NET Core Note: .NET Core has worked around this regression, so it should not be user-impacting.
The following Security and Quality Updates were released this month. Known issues and resolved CVEs are also listed.
The .NET Framework 4.7.1 was released earlier this month. The microsoft/dotnet-framework latest
tag was also updated.
The .NET Framework 4.7.1 is represented by the microsoft/dotnet-framework:4.7.1
tag.
Please share your thoughts on this change and see what others are saying at:
The .NET Framework 4.7.1 image is now available as a Docker image. The latest
tag points to the same image.
The following repos have been updated:
The microsoft/dotnet-framework-samples repo has not yet been updated.
We recommend that you use version-specific tags for production apps. For experimentation or while an application is in development, using the latest
tag is a fine practice.
We recently found a significant performance issue with .NET Framework Docker images. The .NET Framework 4.7.1 image includes the fix for that problem.
This issue has been reserved for a potential future security announcement.
This does not mean a security advisory is coming soon, it simply gives us the ability to predict the issue number that will be used in the future.
Windows Server Version 1709 was released in October. microsoft/nanoserver images have been updated to support Windows Server 1709. These images can be identified with the nanoserver-1709
tag substring.
The following repos have been updated:
Please share your thoughts on this change and see what others are saying at:
.NET Core Docker images now support Windows Server 1709, the latest version of Windows Server.
You can see an example of 1709-based images in the following example.
You can identify Windows Server 1709-based .NET Core images with the tag substring nanoserver-1709
and Windows Server 2016 images with the tag substring nanoserver-sac2016
.
Changes have been made in Windows Server 1709 that affect the compatibility of Windows container images. The practical impact is that Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creative Update hosts cannot load Windows Server 1709 images. Windows 10 Fall Creative Update and Windows Server 1709 can load both original Windows Server 2016 and Windows Server 1709 images. Windows Server 1709 requires Hyper-V isolation (docker run --isolation=hyperv
) in order to load Windows Server 2016 images.
Given the compatibility differences with Windows container images, .NET Core images will adopt manifest lists so that a single logical tag, like 2.0-runtime
, can be used on both older and newer Windows 10 and Windows Server versions. docker pull microsoft/dotnet:2.0-runtime
will pull a Windows Server 2016 image on Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creators Update machines. The same command will pull a Windows Server 1709 based image on Windows Server 1709 and Windows 10 Fall Creators Update machines. The same rules apply to FROM lines.
.NET Framework Docker images are also using manifest lists for the same reason.
You need Docker 17.10 or later to use Windows-version-specific manifest list tags. The following change from the Docker 17.10 release notes is the one that enables this functionality.
You are only recommended to use manifest tags if you want flexibility for development and deployment environments. That's what manifest tags deliver. In general, you should select the most specific tag you can. The more specific the tag, the more predictable the result of each docker pull
and docker build
will be.
Multiple people have reported that .NET Framework performance in Docker images is poor. In the cases reported, performance was an order of magnitude slower than expected.
This issue has now been resolved for microsoft/dotnet-framework images. It was due to incorrectly generated NGEN images. They are now correctly generated and expected performance has been restored.
Please share your thoughts on this change and see what others are saying at:
The .NET Framework uses NGEN as a primary mechanism for startup performance. .NET Framework assemblies are compiled to native code with the NGEN tool as part of the .NET Framework setup process. The benefit of these files is that they can be loaded and executed without any additional significant extra work required by the Common Language Runtime (CLR). The lack of additional work means that performance is very good.
NGEN image generation interacts with a Windows subsystem that is not correctly supported in Windows containers. NGEN images are generated in Windows containers, but they are not valid. Fortunately, the CLR can still run in the presence of invalid images, but code execution is much slower.
We are in the process of fixing Windows containers so that NGEN will work correctly. In the interim, we have updated the dotnet-framework/ images to correctly generate NGEN images. The microsoft/windowsservercore/ images still have the performance problem that was initially reported. We are working on updating Windows containers so that NGEN works as expected. You are recommended to use the dotnet-framework/ base image if you can, so that you can get better performance.
One of the developers that reported the performance issue shared basic performance results. The first two rows are the before state. The last two rows are after the fix. The improvement is quite significant.
Runing
powershell -command (measure-command { powershell -command exit }).TotalSeconds
in various images on our CI server produced this table of timings:
time (s) | image |
---|---|
10.7212372 | microsoft/windowsservercore |
8.3278793 | microsoft/dotnet-framework:4.7 |
0.6426073 | microsoft/dotnet-framework:4.7 (after fix) |
0.1642161 | microsoft/dotnet-framework:4.7.1-windowsservercore-1709 |
.NET Core Docker images can now use multi-stage build using a new feature from Docker that allows multiple FROM
lines to be used in one Dockerfile. The multi-stage build feature was recently introduced into the Docker client Stable channel. Using this feature, you can build a .NET Core app in an SDK image (AKA 'build image') and then copy the published app into a runtime image all in the same Dockerfile. To see an example of this in practice, check out the .NET Docker Samples Repo.
Before the multi-stage build feature was added, a script was required to copy the published output of your build container onto your disk and then the runtime container would read in that output. This was tedious to implement and not super efficient. Now, containers can share build artifacts from different stages within a single Dockerfile.
The Docker Hub README style used by microsoft/dotnet and microsoft/dotnet-nightly has been updated to use a new model that is segmented by OS and chip architecture.
You can see an example of the new style in the following image.
You can share your thoughts on this change or see what others are saying at:
The microsoft/dotnet repo (and by extension microsoft/dotnet-nightly) has been steadily growing with each release of .NET Core and also of the underlying operating systems that we support. We wanted to present simple-to-read tag lists. As the repo has grown, the tag list has gotten longer and more complicated.
The addition of arm32v7
to the repo caused us to spend considerable time thinking about repo organization generally. We looked at other approaches and also talked to Docker employees about their long-term plans for arm32v7
in particular.
We considered various options:
There are three main reasons that we adopted a new README style:
2-sdk
tag. Only one of them can participate in the multi-arch tag while the other variant (in this case Debian 8) is only available with the longer tag name: 2.0.0-sdk-jessie
. The way the bullets in the tag list compose looks odd, as you can see in the following image. It also doesn't communicate the relationship between tags well. arm32v7
is quite limited currently. We wanted to make that obvious.The downside is that this README style is unique (AFAIK). We've never tried to be novel with our Docker offering, but fit into existing conventions. This is our first significant departure from Docker norms. There is a lot changing in the Docker space, with multi-arch and arm32v7
being top of the list (as it relates to this topic). As a result, we thought that now was a good time for experimentation based on the conclusion that the existing README style no longer scales to our needs. Our conversations with Docker employees also led us to believe that there are no good established answers to these challenges.
Please give us your feedback @ dotnet/dotnet-docker #275.
Using System.Net.Http 4.1.0-4.3.0 results in an exception when starting a web app that's .NET 4.6.1:
Details in https://github.com/dotnet/corefx/issues/11100
Updated System.Net.Http 4.3.1 package contains a fix and is available on nuget.
Here's list of technical breaking changes caused by the solution withworkarounds for each.
Note that these new behaviors are specific when running on net46 / Desktop. When you run on .NET Core, the behavior is intact.
HttpClientHandler.CheckCertificateRevocationList
(introduced in System.Net.Http 4.1)
PlatformNotSupportedException
ServicePointManager.CheckCertificateRevocationList
instead (impacts the whole AppDomain, not just single HttpClientHandler
as it did in System.Net.Http 4.1-4.3)HttpClientHandler.SslProtocols
(introduced in System.Net.Http 4.1)
PlatformNotSupportedException
ServicePointManager.SecurityProtocol
instead (impacts the whole AppDomain, not just single HttpClientHandler
as it did in System.Net.Http 4.1-4.3)HttpClientHandler.ServerCertificateCustomValidationCallback
(introduced in System.Net.Http 4.1)
HttpRequestMessage
is always null
ServicePointManager.ServerCertificateValidationCallback
HttpClientHandler
(the normal default handler for HttpClient) but will support HTTP/2.0 protocol. When using HttpClient on .NET Core runtime, the WinHttpHandler is actually built-in to HttpClientHandler. But on .NET Framework, you need to explicitly use WinHttpHandler.HttpRequestMessage.Version
must be explicitly set to 2.0 (the default is normally 1.1). Sample code: var handler = new WinHttpHandler();
var client = new HttpClient(handler);
var request = new HttpRequestMessage(HttpMethod.Get, "http://www.example.com");
request.Version = new Version(2, 0);
HttpResponseMessage response = await client.SendAsync(request);
After much discussion it was decided the best way forward would be to revert the HttpClientHandler implementation in net46 build of CoreFX back to using original .NET Framework HTTP stack instead of WinHTTP (WinHttpHandler) based stack.
Additionally, we will revise the implementation of the new APIs on HttpClientHandler we introduced in 4.1.0.0 OOB package so that it works accordingly for the net46 build. Details and tracking progress.
As a reminder, announcement threads are locked. Please use the original issue for feedback and questions. Thanks!
This issue has been reserved for a potential future security announcement.
This does not mean a security advisory is coming soon, it simply gives us the ability to predict the issue number that will be used in the future.
Copied from Microsoft/Git-Credential-Manager-for-Windows as a public service announcement for the .NET GitHub community. Alternate download location not listed below: https://git-scm.com/.
As of 22 Feb 2018, GitHub has disabled support for weak encryption which means many users will suddenly find themselves unable to authenticate using a Git for Windows which (impacts versions older than v2.16.0). DO NOT PANIC, there's a fix. Update Git for Windows to the latest (or at least v2.16.0).
The most common error users see looks like:
fatal: HttpRequestException encountered.
An error occurred while sending the request.
fatal: HttpRequestException encountered.
An error occurred while sending the request.
Username for 'https://github.com':
If, after updating Git for Windows, you are still having problems authenticating with GitHub, please read this Developer Community topic which contains additional remedial actions you can take to resolve the problem.
If you are experiencing issue when using Visual Studio, please read Unable to connect to GitHub with Visual Studio.
With the release of .NET Core SDK 2.0, the dotnet restore
command is now implicit for commands that require a restore to occur. In most cases, you no longer need to use dotnet restore
. Build systems or other forms of automation may still want to call dotnet restore
explicitly to control the time in which the restore occurs and potential uses of the network.
The following commands implicitly call restore:
new
run
build
publish
pack
test
You can pass --no-restore
to any of these commands to disable implicit restore.
The .NET Core development experience no longer requires explicit use of the dotnet restore
command. This improvement is delivered with the .NET Core 2.0 SDK and works independent of the target framework.
This issue has been reserved for a potential future security announcement.
This does not mean a security advisory is coming soon, it simply gives us the ability to predict the issue number that will be used in the future.
Windows Server Version 1709 was released earlier this month. microsoft/windowsservercore images have been updated to support Windows Server 1709. These images can be identified with the 1709
tag.
The following repos have been updated:
Please share your thoughts on this change and see what others are saying at:
.NET Framework Docker images now support Windows Server 1709, the latest version of Windows Server.
.NET Framework 3.5 and 4.7.1 images are available for Windows Server 1709. Windows Server 1709 includes the .NET Framework 4.7.1. .NET Framework 4.6.2 and .NET Framework 4.7 images are only available with Windows Server 2016 images. You can see an example of 1709-based images in the following example.
You can identify Windows Server 1709-based .NET Framework images with the tag substring windowsservercore-1709
and Windows Server 2016 images with the tag substring windowsservercore-10.0.14393
. You will likely notice that the 1709-based images are easier to identify than the Windows Server 2016 ones.
Changes have been made in Windows Server 1709 that affect the compatibility of Windows container images. The practical impact is that Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creative Update hosts cannot load Windows Server 1709 images. Windows 10 Fall Creative Update and Windows Server 1709 can load both original Windows Server 2016 and Windows Server 1709 images. Windows Server 1709 requires Hyper-V isolation (docker run --isolation=hyperv
) in order to load Windows Server 2016 images.
Given the compatibility differences with Windows container images, .NET Framework images will adopt manifest lists so that a single logical tag, like 4.7.1
, can be used on both older and newer Windows 10 and Windows Server versions. docker pull microsoft/dotnet-framework:4.7.1
will pull a Windows Server 2016 image on Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creators Update machines. The same command will pull a Windows Server 1709 based image on Windows Server 1709 and Windows 10 Fall Creators Update machines. The same rules apply to FROM lines. .NET Core Docker images use this same feature to support Linux and Windows hosts and AMD64 and ARM32 hosts with the same logical tag, like 2.0-runtime
.
The following tags will be updated to use manifest lists:
latest
4.7.1
3.5
You need Docker 17.10 or later to use Windows-version-specific manifest list tags. The following change from the Docker 17.10 release notes is the one that enables this functionality.
You are only recommended to use manifest tags if you want flexibility for development and deployment environments. That's what manifest tags deliver. In general, you should select the most specific tag you can. The more specific the tag, the more predictable the result of each docker pull
and docker build
will be.
Docker has a multi-arch feature that microsoft/dotnet-nightly recently started utilizing. The plan is to port this to the official microsoft/dotnet repo shortly. The multi-arch feature allows a single tag to be used across multiple machine configurations. Without this feature each architecture/OS/platform requires a unique tag. For example, the microsoft/dotnet:1.0-runtime tag is based on Debian and microsoft/dotnet:1.0-runtime-nanoserver if based on Nano Server. With multi-arch there will be one common microsoft/dotnet:1.0-runtime tag. If you pull that tag from a Linux container environment you will get the Debian based image whereas if you pull that tag from a Windows container environment you will get the Nano Server based image. This helps provide tag uniformity across Docker environments thus eliminating confusion.
Current microsoft/dotnet tags:
1.0.5-runtime
, 1.0-runtime
(1.0/debian/runtime/Dockerfile)1.0.5-runtime-nanoserver
, 1.0-runtime-nanoserver
(1.0/nanoserver/runtime/Dockerfile)1.0.5-runtime-deps
, 1.0-runtime-deps
(1.0/debian/runtime-deps/Dockerfile)1.0.5-sdk
, 1.0-sdk
(1.0/debian/sdk/Dockerfile)1.0.5-sdk-nanoserver
, 1.0-sdk-nanoserver
(1.0/nanoserver/sdk/Dockerfile)1.1.2-runtime
, 1.1-runtime
, 1-runtime
, runtime
(1.1/debian/runtime/Dockerfile)1.1.2-runtime-nanoserver
, 1.1-runtime-nanoserver
, 1-runtime-nanoserver
, runtime-nanoserver
(1.1/nanoserver/runtime/Dockerfile)1.1.2-runtime-deps
, 1.1-runtime-deps
, 1-runtime-deps
, runtime-deps
(1.1/debian/runtime-deps/Dockerfile)1.1.2-sdk
, 1.1-sdk
, 1-sdk
, sdk
, latest
(1.1/debian/sdk/Dockerfile)1.1.2-sdk-nanoserver
, 1.1-sdk-nanoserver
, 1-sdk-nanoserver
, sdk-nanoserver
, nanoserver
(1.1/nanoserver/sdk/Dockerfile)2.0.0-preview1-runtime
, 2.0-runtime
, 2-runtime
(2.0/debian/runtime/Dockerfile)2.0.0-preview1-runtime-nanoserver
, 2.0-runtime-nanoserver
, 2-runtime-nanoserver
(2.0/nanoserver/runtime/Dockerfile)2.0.0-preview1-runtime-deps
, 2.0-runtime-deps
, 2-runtime-deps
(2.0/debian/runtime-deps/Dockerfile)2.0.0-preview1-sdk
, 2.0-sdk
, 2-sdk
(2.0/debian/sdk/Dockerfile)2.0.0-preview1-sdk-nanoserver
, 2.0-sdk-nanoserver
, 2-sdk-nanoserver
(2.0/nanoserver/sdk/Dockerfile)New multi-arch microsoft/dotnet-nightly tags:
1.0.5-runtime
, 1.0-runtime
:
1.0.5-runtime-deps
, 1.0-runtime-deps
:
1.0.5-sdk
, 1.0-sdk
:
1.1.2-runtime
, 1.1-runtime
, 1-runtime
, runtime
:
1.1.2-runtime-deps
, 1.1-runtime-deps
, 1-runtime-deps
, runtime-deps
:
1.1.2-sdk
, 1.1-sdk
, 1-sdk
, sdk
, latest
:
2.0.0-preview1-runtime
, 2.0-runtime
, 2-runtime
:
2.0.0-preview1-runtime-deps
, 2.0-runtime-deps
, 2-runtime-deps
:
2.0.0-preview1-sdk
, 2.0-sdk
, 2-sdk
:
This change has been in microsoft/dotnet-nightly for a little over a week. If you have feedback please file an issue on the .NET Core Docker GitHub repo.
The tooling to produce multi-arch tags is still evolving. As a result we found it necessary to create some tooling to build the images and produce the manifest that enables multi-arch. This tooling is open sourced as well.
Updated: January 24, 2018
An issue has been found in the .NET Framework January 2018 Security and Quality Rollup (KB 4055002), applicable to .NET Framework 4.7.1 installed on either Windows 7 and Windows Server 2008 R2.
The .NET team has fixed the issue and re-released the January 2018 Monthly Rollup for affected Windows versions as KB 4074880. Affected machines can be fixed by using one of the solutions described later in the document.
This document describes the symptoms and solutions to resolve the issue.
The .NET Framework January 2018 Monthly Rollup Announcement blog post has been updated with this information.
Please share your thoughts on this change and see what others are saying at:
This issue applies to Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1 machines. Users that install the following products/updates in the following order will experience this issue.
Windows Presentation Foundation (WPF) applications that request a fallback font or a character that is not included in the currently selected font return the following error messages:
System.TypeInitializationException
“FileFormatException: No FontFamily element found in FontFamilyCollection
that matches current OS or greater: Win7SP1”.
Inner exception originates from: CompositeFontParser
To work around this problem, use one of the following methods. We recommend the first option. The other options are provided in the unlikely case that the first option doesn't work for you.
Microsoft has released a Fixit tool for KB4074906, available on Windows Update, WSUS, Microsoft Update Catalog, and as a direct download.
The tool replaces the corrupted font file with the correct version.
The easiest approach is to get the tool via Windows Update or WSUS. If you download and run the tool directly, please follow these instructions.
Important Notes:
You can use the following commands to run the tool and determine the return code.
C:\KB4074906>start /wait FixItTool-KB4074906.exe
C:\KB4074906>echo %errorlevel%
The follow table lists the error codes that the tool outputs:
Case | Code |
---|---|
Success | 0 |
Copy Error | 2 |
File in Use | 33 |
Generic Error | 1603 |
NotApplicable | 20160 |
The January 2018 Monthly Rollup has been re-released with a fix for this known issue. You will have a working system if you uninstall the initial Monthly Rollup (KB 4055002) and instead install updated January 2018 Monthly Rollup (KB 4074880).
Follow these steps:
Manually replace corrupted font file with correct version.
cmd
as Administrator and navigate to %windir%\Microsoft.NET\Framework\v4.0.30319\WPF\Fonts and run:xcopy /y %USERPROFILE%\Downloads\GlobalUserInterface.CompositeFont .
cmd
as Administrator and navigate to %windir%\Microsoft.NET\Framework64\v4.0.30319\WPF\Fonts and run:xcopy /y %USERPROFILE%\Downloads\GlobalUserInterface.CompositeFont .
The root cause of this problem is a MSI setup interaction between the .NET Framework January 2018 Rollup (KB4055002) and an already installed version of .NET Framework 4.7.1 product. The Rollup installer unexpectedly overwrites the 4.7.1 version of the GlobalUserInterface.CompositeFont file. This causes WPF operations that need this font file to fail.
All updates are extensively tested before they are provided to you. We are investigating the gap in our testing and will resolve that for our next release.
We've designed .NET Standard & our tooling so that projects targeting .NET Framework 4.6.1 can consume NuGet packages & projects targeting .NET Standard 2.0 or earlier. Unfortunately, we've seen a few issues around that scenario. The purpose of this document is to summarize the issues, outline our plan on addressing them, and providing workarounds you can deploy with today's state of our tooling.
The primary symptom is that applications crash with a FileLoadException
or a FileNotFoundException
. Another symptom is warnings at build time regarding assembly versions. This is due to one or both of the following issues:
.NET Standard 1.x was based around contracts. Many of these contracts shipped with .NET Framework 4.5 and later. However, different versions of .NET Framework picked up different versions of these contracts, as by-design of contract versioning. As a side effect of marking .NET Framework 4.6.1 as implementing .NET Standard 2.0, some projects will now start picking up binaries built for .NET Standard 1.5 and 1.6 (as opposed to previously where .NET Framework 4.6.1 was considered as implementing .NET Standard 1.4). This results in mismatches of the assembly versions between what was shipped in .NET Framework and what was part of .NET Standard 1.5/1.6.
This can be addressed by binding redirects. As writing them by hand sucks, we added an Automatic Binding Redirect Generation feature in .NET Framework 4.5.1. This feature is opt-in. Unfortunately, it's not enabled based on target framework, but by which target framework was selected when the project was created (as the feature is turned on via an MSBuild property that is conditionally emitted by the template). In practice, this means it's mostly off you often upgrade existing projects, rather than creating new ones.
There are two primary flavors of NuGet: packages.config
and PackageReference
.
With packages.config
, each project has a config file with a flattened graph of all the NuGet dependencies. The project file in turn has direct links to all the assets. The assets are selected at install time. None of this includes indirect NuGet references coming from referenced projects.
With PackageReference
each project contains MSBuild PackageReference
items. The project file contains no references to any assets as the assets are selected at build time. Package restore will compute the graph of all packages, including indirect NuGet references coming from referenced projects.
The default for .NET Framework projects is packages.config
. This ensures more compatibility because PackageReference
doesn't support all the features that packages.config
did, for example, PowerShell install scripts and content.
The only supported mode for SDK-style projects (.NET Core/.NET Standard) is PackageReference
. This means that a .NET Framework project referencing a .NET Standard project ends up crossing the streams between two different NuGet models. When the .NET Standard project references NuGet packages that the .NET Framework project doesn't reference, the application ends up missing all binaries coming from those packages.
Why has this worked before? Because with packages.config
, all dependencies are copied to each project's output folder. MSBuild copies them up from there. With PackageReference
, we don't copy the binaries because it relies on the consuming project to see its dependencies and extract the proper asset itself. This allows the consuming project to pick up the right assets for packages that use bait & switch (which many of the .NET packages must do).
The plan is to address these issues moving forward as follows:
Converge on PackageReference
for all project types, including .NET Framework. The short-term plan for (1) is to start blocking project-to-project references in Visual Studio 15.4 that will end up crossing the streams between packages.config
and PackageReference
. This block is UI only; you can still edit the reference by editing the project by hand. The error message will instruct you to switch the .NET Framework project to PackageReference
if you want to reference a .NET Standard project. Referencing .NET Standard binaries or NuGet packages will not require this, it's only about project-to-project references. In later releases, we plan on providing a converter. The challenge is that packages.config
has features we can't offer for PackagReference
across the board, in particular PowerShell install scripts and content. We'll need good guidance and mitigations, if applicable.
Ensure binding redirects are on by default. Short term, this means we need to fix our target files to make sure we turn on automatic binding redirect generation. However, binding redirects don't work well in all scenarios, when there is no application project (like unit tests or add-ins). We need to work on a plan to bring the regular “higher wins” binding policy without binding redirects. This needs a proposal and proper vetting, but it seems we've reached the point where this is necessary.
packages.config
but uses PackageReference
for NuGet packages
packages.config
, simply add <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
to your project filepackages.config
, convert the contents to packages references in the project file. The syntax is like this:
<PackageReference Include="package-id" Version="package-version" />
web.config
file.PackageReference
like mentioned above. In web sites, you cannot use PackageReference
as there is no project file. In that case, you need to install all NuGet packages into your web site that any of the direct or indirect project references depend on.By default, binding redirects aren't added to class library projects. This is problematic for unit testing projects as they are essentially like apps. So in addition to what's outlined in automatic binding redirects you also need to specify GenerateBindingRedirectsOutputType
:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
For a discussion, please go to dotnet/standard#481.
Please try it out! General feedback can be logged in the .NET Framework Docker issues.
Microsoft/dotnet-framework-docker #22 is open for discussion.
Like the Xml Serializer Generator (sgen.exe) on desktop, Microsoft.XmlSerializer.Generator NuGet package is the solution for .NET Core and .NET Standard Libraries. It creates an Xml serialization assembly for types contained in an assembly in order to improve the startup performance of Xml serialization when serializing or de-serializing objects of those types using XmlSerializer.
You can start using the tool today by following the instructions.
Please share your thoughts and have any discussions with us at:
When the Xml Serializer Generator is not used, an XmlSerializer generates serialization code for each type every time when an application runs. You can improve the startup performance of Xml serialization by simply adding the reference of Microsoft.XmlSerializer.Generator NuGet package to your project. Xml Serializer Generator will generate the serialization code and compile it into an assembly next to your output assembly at build time in advance. This assembly can then be deployed and ran with your application.
Please create an issue with your feedback at dotnet/corefx. We are actively looking to improve the tool and your input is a valuable part of the process.
latest
tag updated to .NET Core 2.0 SDKThe latest
tag for the microsoft/dotnet repo has been updated to reference the .NET Core 2.0 SDK.
You can share your thoughts on this change or see what others are saying at:
The latest
tag for the microsoft/dotnet repo is always intended to reference the latest supported .NET Core SDK. At this time, the latest support SDK is .NET Core SDK 2.0.
The following repos have been updated in the same way:
It is recommended to use a more-specific tag than latest
more anything other than casual development. Once you have an application that you believe will eventually go to production, you are recommended to use a tag like 2.0-sdk
. The .NET Core Docker Samples contains examples of more specific usage such as the .NET Core Development Sample Dockerfile.
Microsoft is releasing this security advisory to provide information about a vulnerability in the public versions of .NET Core 1.0 and 1.1. This advisory also provides guidance on what developers can do to update their applications correctly.
Microsoft is aware of a security vulnerability in the public version of .NET Core where a malformed string request could cause an application to crash and lead to a denial of service.
System administrators are advised to update their .NET Core runtimes to versions 1.0.7 and 1.1.4. Developers are advised to update their .NET Core SDK to version 1.1.4.
Use https://github.com/dotnet/corefx/issues/24703 for discussion of this advisory.
.NET Core 2.0 is not affected by this issue.
,NET Core 1.x applications are only affected if running on Windows 10 or Windows 2016.
Any application running against .NET Core 1.0.6 or lower versions, or 1.1.2 or lower versions is affected. The latest version of the .NET core runtime you have installed in your computer can be listed by running dotnet --info
. Running that command produces an output similar to the following:
.NET Command Line Tools (2.0.2)
Product Information:
Version: 2.0.2
Commit SHA-1 hash: a04b4bf512
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.2\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
As this command only displays the latest version of the runtime installed (or the version set in the global.json file), it may hide the fact that you have a vulnerable runtime. A complete list of runtimes can be discovered by performing a directory listing in the install root directories. The default root directories are listed in the following table:
Operating System | Location |
---|---|
Windows | C:\Program Files\dotnet\shared\Microsoft.NETCore.App\ |
macOS | /usr/local/share/dotnet/shared/Microsoft.NETCore.App/ |
Supported Linux platforms | /usr/share/dotnet/shared/Microsoft.NETCore.App/ |
Each runtime version is installed in its own directory, where the directory name is the version number. If you don't have a directory for 1.0.7 and 1.1.4, then any applications targeting 1.0 or 1.1 of .NET Core are vulnerable.
Also, even if you have a directory for 1.0.7 and 1.1.4 present in your system, if you've deployed self-contained applications targeting the impacted versions, these applications are also vulnerable.
Applications can be fixed by installing the latest .NET Core runtimes or SDKs. Typically, application servers only have runtime packages installed and developer machines have the SDKs installed. Installers for the runtimes can be downloaded from the Runtime and SDK download archive. .NET Core 1.1.4 SDK installs both versions 1.0.7 and 1.1.4 of the .NET Core runtime.
If you've built a self-contained application, you must install the new runtime and SDK, recompile your application and redeploy.
An application can be pinned to a previous version of the runtime by editing the application.runtime.config file for that application. Set the framework version to the desired version and the rollForward
property to false
. These settings should be treated as a temporary measure and the application updated to work with the patched versions of the framework.
Since the application.runtime.config file is an optional file, you may need to create one for each application and add it alongside the executable.
David Fernandez of Sidertia Solutions
CVE-2017-8585
Sidertia blog on their discovery
Version 1.1
Last Updated 2017-18-10
Today at Build 2017 we announced the availability of .NET Core 2.0.0 Preview 1.
Please use dotnet/core #640 for discussion and questions.
.NET designs now have a home on GitHub at dotnet/designs. This repository and the process it uses is intended to be very similar to dotnet/csharplang. We want to share .NET design documents and get much earlier feedback on plans.
The repository was just created. You can see two designs that you can participate on. More designs will show up over time. These two designs were selected as the initial set since the current behavior for both has received significant feedback.
A separate repository was created for a few reasons:
Thanks in advance for your participation in this repository.
In .NET Core SDK 1.0, we introduced a dotnet migrate
command that migrates a project.json-based Preview 2 .NET Core project to a .csproj-based .NET Core SDK 1.0 project. This command was always intended to be only needed in the 1.0 timeframe, to help our early adopters move to the new project system.
In .NET Core SDK 2.0, we are retiring the dotnet migrate
command. Developers who still need to migrate Preview 2 projects after the SDK 2.0 has shipped should first install the 1.0 SDK, migrate their projects, and then install the 2.0 SDK.
See cli#6192 to follow the progress on this change, or to comment on it.
.NET Core 2.0 Docker multi-arch tags now use Debian Stretch instead of Debian Jessie. .NET Core 2.0 Debian Jessie tags will still be provided. Debian Stretch is considered by the .NET Core team to be a better default choice for .NET Core Docker Linux image users for the lifetime of .NET Core 2.x. There are no plans to update .NET Core 1.x in the same way.
The impact of this change should be minimal. It is possible that you may notice differences in Debian Stretch relative to Debian Jessie. This change would be considered a breaking change if it was made for existing 1.x multi-arch tags. It is considered acceptable because it is being made between major .NET versions (during .NET Core 2.0 preview phase).
The latest
tag will be switched to the .NET Core 2.0 SDK when .NET Core 2.0 ships as RTM. This change will result in latest
changing from Debian Jessie to Debian Stretch.
.NET Core 2.0 includes a new opt-in globalization mode that provides basic globalization-related functionality that is uniform across operating systems and languages. The benefit of this new mode is its uniformity, distribution size, and the absence of any globalization dependencies. The downside is that it doesn't actually provide globalization functionality.
This mode is not the default mode in .NET Core, so applications have to opt in. There are no plans to make this mode the default one.
See .NET Core Globalization Invariant Mode to learn more about this feature, and decide whether the new mode is a good choice for your app or if it breaks its functionality.
The globalization areas affected by enabling the globalization invariant mode are:
.NET Standard 2.0 is final.
You can now start producing .NET Standard 2.0 libraries and NuGet packages. Please use the latest .NET Core 2.0 Preview 2 as it contains many improvements that were necessary to provide a good experience.
Bigger API Surface: We have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of the added APIs are .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of UWP.
.NET Framework compatibility mode: The vast majority of NuGet packages are currently still targeting .NET Framework. Many projects are currently blocked from moving to .NET Standard because not all their dependencies are targeting .NET Standard yet. That's why we added a compatibility mode that allows .NET Standard projects to depend on .NET Framework libraries as if they were compiled for .NET Standard. Of course, this may not work in all cases (for instance, if the .NET Framework binaries uses WPF), but we found that 70% of all NuGet packages on nuget.org are API compatible with .NET Standard 2.0, so in practice it unblocks many projects.
In general, make sure you run the latest version of the tooling:
dotnet
) for building packages, so if you only want to use the CLI, you can stop here.Learn more by reading the .NET Standard FAQ.
For discussion, see dotnet/standard#439.
Update: ARM32 is supported with .NET Core 2.1. Download .NET Core 2.1 ARM32 builds.
The .NET Core team is now producing ARM32 builds for .NET Core Runtime 2.0+, for both Linux and Windows. These builds are great for using on Raspberry Pi. The builds are not yet supported by Microsoft and have preview status. Please give us feedback.
Docker ARM32 images are also available at microsoft/dotnet. See microsoft/dotnet Docker Hub README adopts segmented OS/Arch style for a related announcement.
There are two good sources of .NET Core ARM32 samples that you can use to get started:
You can share your thoughts on this change or see what others are saying at:
The team is producing Runtime and not SDK builds for .NET Core. As a result, you need to build your applications on another operating system and then copy to a Raspberry Pi (or similar device) to run. The samples provided above show you how to do that.
You can get builds from the following links. Official builds are not yet provided.
Note that ARM32 is sometimes referred to as armhf
, which refers to hardware floating point capability.
You can remote debug Linux ARM32 applications from a Windows, macOS or Linux machine.
The SDK has not been made available for ARM32 to yet as it doesn't fit within a reasonable performance envelope (space and time) for ARM32. We will resolve this although it isn't a top priority currently (unless feedback suggests otherwise). Our belief is that building on a desktop or build machine will be both more efficient and a reasonable work around to doing development on the Pi for the time being. We also wanted to prioritize the runtime being available since it's necessary for anything to work.
A more near-term need is unit testing on ARM32. There is no replacement for running tests on device. We intend to publish short-term workarounds for this and work on a longer-term solution that is easy to use.
The NuGet package System.ValueTuple has been updated to support .NET Framework 4.7.
The NuGet package provides the ValueTuple
types which are required for the C# tuple syntax. In .NET Framework 4.7 we've added the types directly to mscorlib
. If you use both, the NuGet package, as well as .NET Framework 4.7 you'll end up seeing the same types multipe times. This results in issues like this one reported on Stack Overflow.
We've updated the NuGet package to type forward the tuple types on .NET Framework 4.7 to mscorlib
. This unifies the types and thus allows you to consume other libraries and NuGet packages that depend on System.ValueTuple
while still targeting .NET Framework 4.7.
For discussion, see https://github.com/dotnet/corefx/issues/23085
On first page of this repository, it reads:
Subscribe to this repo to be notified of Announcements and changes in .NET Core.
Does that mean all announcements are related to .NET Core and all products being announced are are open sourced?
If there are announcements about the propitiatory or closed-source products, the products whose sources in full* are not accessible by public, should be marked as such either using a label (https://github.com/dotnet/announcements/labels), or clearly stated in text.
One example is #30, where it is presented to user as if the product ILLink is in open, but the package https://dotnet.myget.org/feed/dotnet-core/package/nuget/Illink.Tasks is produced by script which are nowhere to b found in open. Read more at dotnet/core#915 (comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.