Merge branch 'main' into patch-1

Author: janiceilene

content/actions/creating-actions/metadata-syntax-for-github-actions.md

@@ -299,7 +299,7 @@ runs:
 
 #### `runs.image`
 
-**Required** The Docker image to use as the container to run the action. The value can be the Docker base image name, a local `Dockerfile` in your repository, or a public image in Docker Hub or another registry. To reference a `Dockerfile` local to your repository, use a path relative to your action metadata file. The `docker` application will execute this file.
+**Required** The Docker image to use as the container to run the action. The value can be the Docker base image name, a local `Dockerfile` in your repository, or a public image in Docker Hub or another registry. To reference a `Dockerfile` local to your repository, the file must be named `Dockerfile` and you must use a path relative to your action metadata file. The `docker` application will execute this file.
 
 #### `runs.env`
 

content/actions/learn-github-actions/security-hardening-for-github-actions.md

@@ -77,7 +77,7 @@ This means that a compromise of a single action within a workflow can be very si
 
 ### Considering cross-repository access
 
-{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
+{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
 
 We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
 

content/actions/reference/encrypted-secrets.md

@@ -77,6 +77,12 @@ When generating credentials, we recommend that you grant the minimum permissions
 
 If your repository {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0"or currentVersion == "github-ae@latest" %}has environment secrets or {% endif %}can access secrets from the parent organization, then those secrets are also listed on this page.
 
+{% note %}
+
+**Note:** Users with collaborator access can use the REST API to manage secrets for a repository. For more information, see "[{% data variables.product.prodname_actions %} secrets API](/rest/reference/actions#secrets)."
+
+{% endnote %}
+
 {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@latest" }
 ### Creating encrypted secrets for an environment
 

content/github/authenticating-to-github/using-ssh-over-the-https-port.md

@@ -33,6 +33,7 @@ To set this in your ssh config, edit the file at `~/.ssh/config`, and add this s
 Host {% data variables.command_line.codeblock %}
   Hostname ssh.{% data variables.command_line.codeblock %}
   Port 443
+  User git
 ```
 
 You can test that this works by connecting once more to {% data variables.product.product_location %}:

content/github/using-git/updating-credentials-from-the-macos-keychain.md

@@ -31,7 +31,7 @@ protocol=https
 > <em>[Press Return]</em>
 ```
 
-If it's successful, nothing will print out. To test that it works, try and clone a repository from {% data variables.product.product_location %}. If you are prompted for a password, the keychain entry was deleted.
+If it's successful, nothing will print out. To test that it works, try and clone a private repository from {% data variables.product.product_location %}. If you are prompted for a password, the keychain entry was deleted.
 
 ### Further reading
 

content/github/working-with-github-pages/changing-the-visibility-of-your-github-pages-site.md

@@ -11,7 +11,14 @@ permissions: People with admin permissions for a repository can change the visib
 
 If your project site is published from a private or internal repository that's owned by an organization using {% data variables.product.prodname_ghe_cloud %}, you can manage access control for the site. With access control, you can choose to publish the site publicly to anyone on the internet or privately to people with read access to your repository. A privately published site can be used to share your internal documentation or knowledge base with members of your enterprise. You cannot manage access control for an organization site. For more information about the types of {% data variables.product.prodname_pages %} sites, see "[About GitHub Pages](/github/working-with-github-pages/about-github-pages#types-of-github-pages-sites)." 
 
-Privately published sites are available at a different subdomain than publicly published sites. You can see your site's URL in the repository settings. If you're using a static site generator configured to build the site with the repository name as a path, you may need to update the settings for the static site generator when changing the site to private. For more information, see "[Configuring Jekyll in your {% data variables.product.prodname_pages %} site](/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-a-subdomain)" or the documentation for your static site generator.
+Privately published sites are available at a different subdomain than publicly published sites. This ensures that your {% data variables.product.prodname_pages %} site is secure from the moment it's published:
+
+- We automatically secure every subdomain of `*.pages.github.io` with a TLS certificate, and enforce HSTS to ensure that browsers always serve the page over HTTPS.
+- We use a unique subdomain for the private page to ensure that other repositories in your organization cannot publish content on the same origin as the private page. This protects your private page from "[cookie tossing](https://github.blog/2013-04-09-yummy-cookies-across-domains/)". This is also why we don't host {% data variables.product.prodname_pages %} sites on the `github.com` domain.
+
+You can see your site's unique subdomain in the pages tab of your repository settings. If you're using a static site generator configured to build the site with the repository name as a path, you may need to update the settings for the static site generator when changing the site to private. For more information, see "[Configuring Jekyll in your {% data variables.product.prodname_pages %} site](/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-a-subdomain)" or the documentation for your static site generator.
+
+To use a shorter and more memorable domain for your private {% data variables.product.prodname_pages %} site, you can configure a custom domain. For more information, see "[Configuring a custom domain for your {% data variables.product.prodname_pages %} site](/github/working-with-github-pages/configuring-a-custom-domain-for-your-github-pages-site)."
 
 ### Changing the visibility of your {% data variables.product.prodname_pages %} site
 

data/release-notes/3-0/0.yml

@@ -1,6 +1,8 @@
 date: '2021-02-16'
 intro: The minimum infrastructure requirements have increased for {% data variables.product.prodname_ghe_server %} 3.0+. For more information, see "[About minimum requirements for GitHub Enterprise Server 3.0 and later](/admin/enterprise-management/upgrading-github-enterprise-server#about-minimum-requirements-for-github-enterprise-server-30-and-later)."
 sections:
+  security_fixes:
+    - '**HIGH:** A remote code execution vulnerability was identified in {% data variables.product.prodname_ghe_server %} that could be exploited when building a {% data variables.product.prodname_pages %} site. User-controlled configuration of the underlying parsers used by {% data variables.product.prodname_pages %} were not sufficiently restricted and made it possible to execute commands on the {% data variables.product.prodname_ghe_server %} instance. To exploit this vulnerability, an attacker would need permission to create and build a {% data variables.product.prodname_pages %} site on the {% data variables.product.prodname_ghe_server %} instance. This vulnerability has been assigned CVE-2020-10519 and was reported via the [GitHub Bug Bounty Program](https://bounty.github.com).'
   features:
     - heading: GitHub Actions
       notes:

data/reusables/github-actions/expression-syntax-if.md

@@ -1 +1 @@
-When you use expressions in an `if` conditional, you may omit the expression syntax ({% raw %}`${{ }}`{% endraw %}) because {% data variables.product.prodname_dotcom %} automatically evaluates the `if` conditional as an expression.
+When you use expressions in an `if` conditional, you may omit the expression syntax ({% raw %}`${{ }}`{% endraw %}) because {% data variables.product.prodname_dotcom %} automatically evaluates the `if` conditional as an expression, unless the expression contains any operators. If the expression contains any operators, the expression must be contained within {% raw %}`${{ }}`{% endraw %} to explicitly mark it for evaluation.

lib/redirects/external-sites.json

@@ -14,7 +14,7 @@
   "/git-scm": "https://git-scm.com/",
   "/git-user-manual": "http://schacon.github.com/git/user-manual.html",
   "/github-status": "https://status.github.com/messages",
-  "/github-support": "https://support.github.com/contact",
+  "/github-support": "https://support.github.com",
   "/multiple-keys": "https://developer.github.com/guides/managing-deploy-keys",
   "/pro-git": "https://git-scm.com/book",
   "/submodules": "https://git-scm.com/book/en/Git-Tools-Submodules",