DOCSEARCHbyAlgolia
Submit Docs

.NET Release Notes and Core Documentation

repository·main·Indexed 12 days ago

https://github.com/dotnet/core

Central hub for .NET release notes, versioning information, and security foundations. Includes support status for .NET 8.0 (LTS), 9.0 (STS), 10.0 (LTS), and 11.0 (STS) previews, as well as guidelines on security design posture, vulnerability theory, and bug bounty scopes. Provides a comprehensive directory of specialized repositories for the .NET runtime, SDK, compilers, libraries, and app workloads.

Tokens
13.4K
Snippets
14
Records
69
Agent score
98%

What's inside .NET

  1. View .NET Release Notes and Versions

    main

    The .NET repository provides detailed release notes for all supported versions. You can find specific information for each version (such as new features, breaking changes, and bug fixes) by navigating to the version-specific documentation.

    Current Release Status (as of August 2026):

    • .NET 11.0 (STS): Currently in Preview (e.g., 11.0.0-preview.7).
    • .NET 10.0 (LTS): Active support (Latest Patch: 10.0.11). Support ends November 14, 2028.
    • .NET 9.0 (STS): Maintenance phase (Latest Patch: 9.0.19). Support ends November 10, 2026.
    • .NET 8.0 (LTS): Maintenance phase (Latest Patch: 8.0.30). Support ends November 10, 2026.

  2. Understand .NET security framing and design posture

    main

    The .NET security posture is built around its role as a provider of reusable libraries and SDK components. Security designs, component contracts, and vulnerability assessments are guided by specific framing documents that account for the unique nature of being a library provider rather than a standalone application.

    Key pillars of this posture include:

    • Security Designs: How components are architected to be secure.
    • Component Contracts: The expectations and responsibilities shared between .NET components and their users.
    • Vulnerability Assessment: The methodology used to evaluate reported security issues.

  3. Understand .NET licensing for source code, products, and packages

    main

    The licensing for .NET depends on whether you are using the source code, product distributions, or library packages:

    • Source Code: The .NET project uses the MIT license. Each individual repository contains its own specific license and a THIRD-PARTY-NOTICES.TXT file.
    • Product Distributions:
      • On Linux and macOS: Uses the MIT license.
      • On Windows: Uses the .NET Library License.
      • This includes downloadable assets and runtime packs.
    • Package Distributions: Library packages (e.g., System.Text.Json on NuGet) use the MIT license.

    Redistribution of Binaries: Binaries produced by .NET SDK compilers (C#, F#, VB) can be redistributed without additional restrictions, provided the license of the compiler inputs is respected. Applications are subject to the terms defined in 'Product distributions' and 'Package distributions'.

  4. Identify commercial support providers for .NET

    main

    If you require commercial support for .NET on Windows or Linux, several organizations provide specialized services:

    • Canonical: Supports .NET on Ubuntu (specifically .NET 6 and .NET 8 on Ubuntu 22.04+).
    • HeroDevs: Provides 'Never Ending Support (NES)' for .NET 6+ on Windows and Linux.
    • Microsoft: Provides stable builds and commercial support across multiple operating systems.
    • Red Hat: Supports .NET on Red Hat Enterprise Linux (RHEL).
    • TuxCare: Provides commercial support for certain out-of-support .NET versions on Windows and Linux across multiple distributions.

  5. Understand the difference between Microsoft and Distro-provided packages

    main

    There are two main sources for .NET packages on Linux:

    1. Distribution Archives: Provided by the Linux distribution itself. These SDK builds are always within the .1xx feature band.
    2. Microsoft Archives: Provided at packages.microsoft.com. These SDK builds are always for the latest feature band (e.g., .2xx).

    Microsoft's builds allow access to the latest SDK feature bands, whereas distro-provided builds may lag behind the latest feature release.

  6. Understand in-process and out-of-process composition boundaries

    main

    The security model defines how components interact based on their execution context and authority.

    In-process Composition

    • No Security Boundary: .NET does not provide or enforce intra-process sandboxing.
    • Full Trust: Every component loaded into a process is considered fully trusted with respect to every other component in that same process. Any code in the process can control the execution flow of any other code in that process.

    Out-of-process Composition

    • Continuity of Authority: If a component (a "helper") is executed out-of-process under the same authority (e.g., the same user account and equal/higher integrity level), it remains fully trusted.
    • Authority Transitions: A process boundary is not a security boundary unless there is an authority transition.
      • Overt Transitions: Launching a helper on a different machine, under a different user account, or in a less-privileged AppContainer.
      • Subtle Transitions: Using communication mechanisms like named pipes or TCP sockets (even on localhost) can be subject to interference by processes with different authorities. These require mutual authentication.
      • In-band Mechanisms: Mechanisms like stdin/stdout established at process creation preserve continuity of authority.

  7. Treat environment variables as control-plane instructions

    main

    Environment variables are considered fully trusted because they are set by a host authority capable of launching the application. They are intended to carry control-plane instructions (e.g., execution environment info, configuration, dependency locations).

    Handling Opaque Data in Environment Variables

    In scenarios like cgi-bin handlers, environment variables (e.g., HTTP_*) may carry opaque data from untrusted actors rather than control-plane instructions.

    To safely pass untrusted data via environment variables, there must be an explicit, documented contract between the host and the target application that defines:

    1. How to distinguish variables containing control-plane instructions from those carrying opaque data.
    2. What semantics apply to each variable carrying opaque data.

    Without this agreement, the target application may treat all environment variables as fully trusted control-plane instructions.

  8. How package compatibility and targeting work

    main

    Packages generally retain compatibility for all .NET versions that are currently in support. A package will not drop support for a .NET version while that version is still supported. However, once a .NET version reaches End of Life, packages released after that point may drop support for it.

    Packages achieve multi-version support through one of two technical approaches:

    • Multi-targeting: A single project is built for multiple target frameworks, resulting in a single NuGet package containing assets for multiple .NET versions.
    • Branching: Separate projects are built in different branches, each targeting a specific framework, resulting in multiple distinct packages that each contain a single asset for a specific .NET version.

  9. Distinguish between a vulnerability and a reliability bug

    main

    A critical distinction in security modeling is whether a defect results in an improper privilege grant.

    • Reliability Bug: An unwanted behavior that does not facilitate a privilege grant. For example, a file management tool that accidentally deletes a file instead of renaming it is a reliability bug if the user already had the privilege to delete that file. It is a defect, but not a vulnerability.
    • Vulnerability: A defect that results in an entity (the subject) gaining a grant set (set of privileges) they were not intended to have. For example, if a tool makes a temporary copy of a file in a public location during a rename, it grants a privilege to other entities to read that data, which constitutes a vulnerability.

    Corollary: A behavior that does not facilitate a privilege grant is not a vulnerability, even if it is unwanted.

  10. OpenSSL compatibility for portable builds

    main
    .NET portable builds support both OpenSSL 1.x and 3.x. They can run on distributions containing either version. By default, the highest OpenSSL version available on the system is loaded, but it can be configured to use a specific version if necessary.

  11. Understand .NET's definition of a security vulnerability

    main

    This document outlines the theoretical framework .NET uses to define a security bug (a "vulnerability"). This definition is used by the .NET team to triage security reports and distinguish between true vulnerabilities and reliability bugs. The framework is based on the CWE working group's theory and U.S. FISMA (2014) definitions, focusing on authority boundaries and the CIA (Confidentiality, Integrity, Availability) properties.

    Key distinctions include:

    • Vulnerability vs. Reliability Bug: A formal distinction is made to ensure consistent triaging.
    • Trigger, Subject, and Causation: The theory analyzes how an adversary interacts with the system.
    • Adversary Role: Distinguishes between an adversary acting as a 'trigger' versus an adversary acting as a 'subject'.
    • Availability: Addresses how denial of service (DoS) impacts the definition of a vulnerability.

  12. Identify signs of bad-faith activity

    main

    When evaluating whether a user is acting in bad faith, look for the following signals, often found by inspecting user profiles:

    High bias toward bad-faith indicators:

    • New accounts: The account was created very recently.
    • Private profiles: The user's profile information is hidden.
    • Repeated patterns: The public profile shows similar repeated activity across other repositories or organizations.

    Distinguishing between skill gaps and bad actors:

    • Genuine participants: Users who lack experience or skills typically identify themselves through different signals. They generally do not attempt massive, high-impact changes (like 5000-file PRs or CI infrastructure updates) as their first interaction.
    • Bad actors: Often attempt to hide malicious payloads within large or complex "contributions" to mask their intent.