Merge branch 'main' of https://github.com/dotnet/sdk into darc-main-86b63178-e6e0-4baf-80a2-68fa2bb61b88

Author: Jason Zhai

.github/policies/resourceManagement.yml

@@ -77,18 +77,10 @@ configuration:
       - labelAdded:
           label: breaking-change
       then:
-      - addLabel:
-          label: needs-breaking-change-doc-created
       - addReply:
           reply: >-
-            Added `needs-breaking-change-doc-created` label because this issue has the `breaking-change` label. 
-
-
-            1. [ ] Create and link to this issue a matching issue in the dotnet/docs repo using the [breaking change documentation template](https://aka.ms/dotnet/docs/new-breaking-change-issue), then remove this `needs-breaking-change-doc-created` label.
-
-
-            Tagging @dotnet/compat for awareness of the breaking change.
-      description: Add breaking change doc label to issue
+            Refer to the [.NET SDK breaking change guidelines](https://github.com/dotnet/sdk/blob/main/documentation/project-docs/breaking-change-guidelines.md#required-process-for-all-net-sdk-breaking-changes)
+      description: Add breaking change doc instructions to issue
     - if:
       - payloadType: Pull_Request
       - labelAdded:
@@ -106,10 +98,10 @@ configuration:
 
             1. [ ] Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the [breaking change documentation template](https://aka.ms/dotnet/docs/new-breaking-change-issue), then remove this `needs-breaking-change-doc-created` label.
 
-            2. [ ] Ask a committer to mail the `.NET Breaking Change Notification` DL.
+            2. [ ] Ask a committer to mail the `.NET SDK Breaking Change Notification` email list.
 
 
-            Tagging @dotnet/compat for awareness of the breaking change.
-      description: Add breaking change doc label to PR
+            You can refer to the [.NET SDK breaking change guidelines](https://github.com/dotnet/sdk/blob/main/documentation/project-docs/breaking-change-guidelines.md)
+      description: Add breaking change instructions to PR.
 onFailure: 
 onSuccess: 

.vsts-ci.yml

@@ -285,7 +285,7 @@ extends:
             name: Azure Pipelines
             image: macOS-latest
             os: macOS
-          helixTargetQueue: osx.13.amd64
+          helixTargetQueue: osx.15.amd64
           oneESCompat:
             templateFolderName: templates-official
             publishTaskPrefix: 1ES.
@@ -313,7 +313,7 @@ extends:
               name: Azure Pipelines
               vmImage: macOS-latest
               os: macOS
-            helixTargetQueue: osx.13.arm64
+            helixTargetQueue: osx.15.arm64
             macOSJobParameterSets:
             - categoryName: TestBuild
               buildArchitecture: arm64

.vsts-pr.yml

@@ -68,7 +68,7 @@ stages:
         name: Azure Pipelines
         vmImage: macOS-latest
         os: macOS
-      helixTargetQueue: osx.13.amd64.open
+      helixTargetQueue: osx.15.amd64.open
   ### ARM64 ###
   - ${{ if eq(parameters.enableArm64Job, true) }}:
     - template: /eng/pipelines/templates/jobs/sdk-job-matrix.yml
@@ -77,7 +77,7 @@ stages:
           name: Azure Pipelines
           vmImage: macOS-latest
           os: macOS
-        helixTargetQueue: osx.13.arm64.open
+        helixTargetQueue: osx.15.arm64.open
         macOSJobParameterSets:
         - categoryName: TestBuild
           buildArchitecture: arm64

documentation/general/trust-code.md

@@ -0,0 +1,19 @@
+# Overview
+The .NET SDK is intended to be a collection of tools for manipulating, building, and executing code. As a result, there is no way to ensure that it is 100% secure regardless of how it is used. This document attempts to make clear the line between what security threats are up to the user and what threats the SDK should protect against. It defines the trust boundary where the user can assume that as long as they are secure in the ways outlined in this document, they will not be compromised by an outside threat actor.
+
+# Types of Threats
+
+## Untrusted Source Code
+You should never build or run code from an untrusted source without employing mitigating factors like those described [here](ExecutingCustomerCode.md). Additionally, some SDK commands will automatically find code or code-adjacent files in the current directory, project directory, executable directory, or any parent directory of any of those up to the file system root. Files that may affect a build or other command if found include but are not limited to a Directory.Build.props, global.json, NuGet.config, or dotnet-tools.json. You should also check your home folder as well as environment variables that may point to other locations the SDK will search to find code or configuration files.
+
+## Untrusted Locations
+Some folders often store untrusted files. (The Downloads folder is a fairly straightforward example of that.) Some commands look "next to" the project, solution, or other code file being worked with in the directory. Do not run dotnet CLI commands from within any directory that contains any files you do not trust.
+
+## Untrusted Packages
+Since many SDK commands utilize NuGet under the covers, we further assume that:
+* NuGet packages in local caches are trustworthy.
+* NuGet.Config, Packages.Config, .props, and similar files within our resolution scope (see previous comments on trusted and untrusted directories) point only to trusted package repositories and/or packages.
+
+See: [Managing the global packages and cache folders](https://learn.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders), [Managing package trust boundaries](https://learn.microsoft.com/nuget/consume-packages/installing-signed-packages), and [Consuming packages from authenticated feeds](https://learn.microsoft.com/nuget/consume-packages/consuming-packages-authenticated-feeds) for more information.
+
+Violating these assumptions may lead to unwanted code execution.