Merge branch 'main' into patch-1

Author: Sharra-writes

content/actions/how-tos/reuse-automations/reuse-workflows.md

@@ -59,7 +59,7 @@ You can define inputs and secrets, which can be passed from the caller workflow
      reusable_workflow_job:
        runs-on: ubuntu-latest
        steps:
-       - uses: actions/labeler@v4
+       - uses: actions/labeler@v5
          with:
            repo-token: ${{ secrets.personal_access_token }}
            configuration-path: ${{ inputs.config-path }}
@@ -99,7 +99,7 @@ jobs:
   triage:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/labeler@v4
+    - uses: actions/labeler@v5
       with:
         repo-token: ${{ secrets.token }}
         configuration-path: ${{ inputs.config-path }}

content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits.md

@@ -108,11 +108,8 @@ By default, the rate limit for {% data variables.product.prodname_actions %} is
 
 If the number of AJAX requests to your {% data variables.product.prodname_ghe_server %} instance causes problems, then you may need to edit the rate limit for the WebSockets controller used by these live updates. For details of how to view Alive requests, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-the-monitor-dashboards).
 
-By default, a maximum of 100 requests is allowed per minute for each IP address. Administrators with access to the administrative shell can use the [ghe-config](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config) utility to set `app.github.web-sockets-rate-limit` with the number of requests allowed per minute for each IP address or disable this rate limit. Setting the limit to any value that is not a positive integer (for example, `0`, `-1`, `disabled`) disables rate limiting on the WebSockets controller for live updates.
+When primary rate limits are enabled, by default a maximum of 100 requests is allowed per minute for each IP address. Administrators with access to the administrative shell can use the [ghe-config](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config) utility to set `app.github.web-sockets-rate-limit` with the number of requests allowed per minute for each IP address or disable this rate limit. Setting the limit to any value that is not a positive integer (for example, `0`, `-1`, `disabled`) disables rate limiting on the WebSockets controller for live updates.
 
 {% data reusables.github-connect.rate-limit-live-dotcom-requests %}
 
-> [!IMPORTANT]
-> This rate limit will not apply until you also enable the global rate limiter directly using `ghe-config app.github.rate-limiting-enabled 1` or indirectly by enabling rate limits for the {% data variables.product.prodname_enterprise_api %}](#enabling-rate-limits-for-the-github-enterprise-server-apis). When you enable the global rate limiter, other {% data variables.product.github %} features may also experience rate limits. Monitor your instance closely to check for any unexpected request rejections.
-
 After you make any changes to the values of these settings, run [ghe-config-apply](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-config-apply) to apply the settings.

content/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/accessing-user-owned-repositories-in-your-enterprise.md

@@ -13,9 +13,6 @@ redirect_from:
   - /admin/user-management/managing-repositories-in-your-enterprise/accessing-user-owned-repositories-in-your-enterprise
 ---
 
-> [!NOTE]
-> Temporarily accessing user-owned repositories is currently in {% data variables.release-phases.public_preview %} for {% data variables.product.prodname_emus %} and subject to change.
-
 ## About temporary access to user-owned repositories
 
 If your enterprise uses {% data variables.product.prodname_emus %}, and you've allowed users to create repositories owned by their user accounts, you can temporarily access any user-owned repository within your enterprise.

content/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/viewing-user-owned-repositories-in-your-enterprise.md

@@ -13,9 +13,6 @@ redirect_from:
   - /admin/user-management/managing-repositories-in-your-enterprise/viewing-user-owned-repositories-in-your-enterprise
 ---
 
-> [!NOTE]
-> Viewing user-owned repositories is currently in {% data variables.release-phases.public_preview %} for {% data variables.product.prodname_emus %} and subject to change.
-
 If your enterprise uses {% data variables.product.prodname_emus %}, and you've allowed users to create repositories owned by their user accounts, you can view all user-owned repositories within your enterprise.
 
 You can also temporarily access any user-owned repository. For more information, see [AUTOTITLE](/admin/user-management/managing-repositories-in-your-enterprise/accessing-user-owned-repositories-in-your-enterprise).

content/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app.md

@@ -30,29 +30,33 @@ If you do hit a rate limit and need to retry an API request, use the `x-ratelimi
 
 ## Secure your app's credentials
 
-You can generate a private key and client secret for your {% data variables.product.prodname_github_app %}. With these credentials, your app can generate installation access tokens, user access tokens, and refresh tokens. These tokens can be used to make API requests on behalf of an app installation or user.
+You can generate a private key and client secret for your {% data variables.product.prodname_github_app %}. Private keys are used to generate installation access tokens, while client secrets are used to get user access tokens and refresh tokens. These tokens can be used to make API requests on behalf of an app installation or user.
 
-You must store these credentials securely. The storage mechanism depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
+You must store private keys, tokens, and client secrets securely. However, the storage mechanism and its relative security depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
 
 ### Private keys
 
-The private key for your {% data variables.product.prodname_github_app %} grants access to every account that the app is installed on.
+The private key for your {% data variables.product.prodname_github_app %} grants access to every account that the app is installed on. It **must** be stored securely and never shared broadly.
 
 Consider storing your {% data variables.product.prodname_github_app %}'s private key in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/en-gb/products/key-vault), and making it sign-only.
 
 Alternatively, you can store the key as an environment variable. However, this is not as strong as storing the key in a key vault. If an attacker gains access to the environment, they can read the private key and gain persistent authentication as the {% data variables.product.prodname_github_app %}.
 
-You should never hard code your private key in your app, even if your code is stored in a private repository. If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you should never ship your private key with your app.
+You should never hard code your private key in your app, even if your code is stored in a private repository. If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you must never ship your private key with your app.
 
-You should not generate more private keys than you need. You should delete private keys that you no longer need. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps).
+You should not generate more private keys than you need. You should delete private keys that are no longer in use. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps).
 
 ### Client secrets
 
-Client secrets are used to generate user access tokens for your app, unless your app uses device flow. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-device-flow-to-generate-a-user-access-token).
+Client secrets are required to generate user access tokens for your app, unless your app uses the device flow. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-device-flow-to-generate-a-user-access-token).
 
-If your app is a website or web app, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
+If your app is a confidential client, meaning it can safely keep the client secret secure, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
 
-If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you cannot secure your client secret. You should use caution if you plan to gate access to your own services based on tokens generated by your app because anyone can access the client secret to generate a token.
+If your app is a public client (a native app that runs on the user's device, CLI utility, or single-page web application), you cannot secure your client secret. You will have to ship the client secret in the application's code, and you should use PKCE to better secure the authentication flow. You should use caution if you plan to gate access to your own services based on tokens generated by your app because public clients are trivially spoofable - anyone can reuse your app's client ID to sign in.
+
+#### Don't enable device flow without reason
+
+It is preferable to use the authorization code with PKCE over the device flow, if you are concerned about using the client secret in a public client. The device flow does not require redirect URIs at all, which means that an attacker can use the device flow to remotely impersonate your app as part of a phishing attack. For this reason, do not enable the device flow for your application unless you are using the app in a constrained environment (CLIs, IoT devices, or headless systems).
 
 ### Installation access tokens, user access tokens, and refresh tokens
 

content/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app.md

@@ -50,13 +50,19 @@ To find the list of organizations a user is a member of, you can use the "List o
 
 With a client secret, your app can authorize a user and generate user access tokens. These tokens can be used to make API requests on behalf of a user.
 
-You must store your app's client secret and any generated tokens securely. The storage mechanism depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
+You must store your app's client secret and any generated tokens securely. The storage mechanism and its relative security depends on your integrations architecture and the platform that it runs on. In general, you should use a storage mechanism that is intended to store sensitive data on the platform that you are using.
 
 ### Client secrets
 
-If your app is a website or web app, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
+Client secrets are required to generate user access tokens for your app, unless your app uses the device flow. For more information, see [AUTOTITLE](/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow).
 
-If your app is a native client, client-side app, or runs on a user device (as opposed to running on your servers), you cannot secure your client secret. You should use caution if you plan to gate access to your own services based on tokens generated by your app, because anyone can access the client secret to generate a token.
+If your app is a confidential client, meaning it can safely keep the client secret secure, consider storing your client secret in a key vault, such as [Azure Key Vault](https://azure.microsoft.com/products/key-vault), or as an encrypted environment variable or secret on your server.
+
+If your app is a public client (a native app that runs on the user's device, CLI utility, or single-page web application), you cannot secure your client secret. You will have to ship the client secret in the application's code, and you should use PKCE to better secure the authentication flow. You should use caution if you plan to gate access to your own services based on tokens generated by your app because public clients are trivially spoofable - anyone can reuse your app's client ID to sign in.
+
+#### Don't enable device flow without reason
+
+It is preferable to use the authorization code with PKCE over the device flow, if you are concerned about using the client secret in a public client. The device flow does not require redirect URIs at all, which means that an attacker can use the device flow to remotely impersonate your app as part of a phishing attack. For this reason, do not enable the device flow for your application unless you are using the app in a constrained environment (CLIs, IoT devices, or headless systems).
 
 ### User access tokens
 

content/billing/how-tos/products/view-product-use.md

@@ -41,7 +41,7 @@ contentType: how-tos
 
 Anyone can view usage for their own personal account.
 
-If you have an owner or billing manager role for an organization, an organization account, or enterprise account, you will also have access to usage data for that organization or account.
+If you are an owner or billing manager of an organization or enterprise, you will also have access to usage data for that organization or account.
 
 ### Personal accounts
 

content/copilot/concepts/about-mcp.md

@@ -25,7 +25,7 @@ For more information on MCP, see [the official MCP documentation](https://modelc
 
 To learn how to configure and use MCP servers with {% data variables.copilot.copilot_chat_short %}, see [AUTOTITLE](/copilot/how-tos/context/model-context-protocol/extending-copilot-chat-with-mcp).
 
-Enterprises and organizations can choose to enable or disable use of MCP for members of their organization or enterprise. See [AUTOTITLE](/copilot/how-tos/administer/enterprises/managing-policies-and-features-for-copilot-in-your-enterprise#mcp-servers-on-githubcom). The MCP policy only applies to members with {% data variables.copilot.copilot_business_short %}, {% data variables.copilot.copilot_enterprise_short %}, or {% data variables.product.prodname_copilot_short %} licenses assigned by the organization or enterprise that configures the policy. {% data variables.copilot.copilot_free_short %}, {% data variables.copilot.copilot_pro_short %}, or {% data variables.copilot.copilot_pro_plus_short %} do not have their MCP access governed by this policy.
+{% data reusables.copilot.mcp.mcp-policy %}
 
 ## About the {% data variables.product.github %} MCP server
 

content/copilot/how-tos/provide-context/use-mcp/extend-copilot-chat-with-mcp.md

@@ -5,6 +5,7 @@ shortTitle: Extend Copilot Chat with MCP
 intro: 'Learn how to use the Model Context Protocol (MCP) to extend {% data variables.copilot.copilot_chat_short %}.'
 versions:
   feature: copilot
+defaultTool: vscode
 topics:
   - Copilot
 redirect_from:
@@ -29,7 +30,7 @@ For information on currently available MCP servers, see [the MCP servers reposit
 
 {% vscode %}
 
-Enterprises and organizations can choose to enable or disable use of MCP for members of their organization or enterprise. See [AUTOTITLE](/copilot/how-tos/administer/enterprises/managing-policies-and-features-for-copilot-in-your-enterprise#mcp-servers-on-githubcom). The MCP policy only applies to members with {% data variables.copilot.copilot_business_short %}, {% data variables.copilot.copilot_enterprise_short %}, or {% data variables.product.prodname_copilot_short %} licenses assigned by the organization or enterprise that configures the policy. {% data variables.copilot.copilot_free_short %}, {% data variables.copilot.copilot_pro_short %}, or {% data variables.copilot.copilot_pro_plus_short %} do not have their MCP access governed by this policy.
+{% data reusables.copilot.mcp.mcp-policy %}
 
 ## Prerequisites
 

content/copilot/how-tos/provide-context/use-mcp/use-the-github-mcp-server.md

@@ -4,6 +4,7 @@ intro: 'Learn how to use the GitHub Model Context Protocol (MCP) server to exten
 shortTitle: Use the GitHub MCP Server
 versions:
   feature: copilot
+defaultTool: vscode
 topics:
   - Copilot
 redirect_from: