Repo sync

content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise.md

@@ -151,24 +151,6 @@ Across all organizations owned by your enterprise, you can set the default branc
 1. Optionally, to enforce the default branch name for all organizations in the enterprise, select **Enforce across this enterprise**.
 1. Click **Update**.
 
-{% ifversion deploy-keys-enterprise-org-policy %}
-
-## Enforcing a policy for deploy keys
-
-Across all organizations owned by your enterprise, you can allow members to create deploy keys in repositories, restrict deploy key creation, or allow owners to administer the setting on the organization level.
-
-For more information about using deploy keys, see "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)." If you want fine-grained control over permissions, consider using a {% data variables.product.prodname_github_app %} instead. See "[AUTOTITLE](/apps/overview)."
-
-> [!WARNING]
-> Changing this setting to disabled will result in existing deploy keys being disabled in all repositories in your enterprise.
-
-{% data reusables.enterprise-accounts.access-enterprise %}
-{% data reusables.enterprise-accounts.policies-tab %}
-{% data reusables.enterprise-accounts.repositories-tab %}
-1. Under "Deploy keys", review the information about changing the setting, then select a policy.
-1. Click **Save**.
-{% endif %}
-
 ## Enforcing a policy for changes to repository visibility
 
 Across all organizations owned by your enterprise, you can allow members with admin access to change a repository's visibility, restrict repository visibility changes to organization owners, or allow owners to administer the setting on the organization level. When you prevent members from changing repository visibility, only enterprise owners can change the visibility of a repository.

content/authentication/connecting-to-github-with-ssh/managing-deploy-keys.md

@@ -69,8 +69,6 @@ See [our guide on creating a {% data variables.product.pat_generic %}](/authenti
 
 {% data reusables.repositories.deploy-keys-write-access %}
 
-For enhanced security and fine-grained control over repository access and permissions, we recommend using a GitHub App instead. See "[AUTOTITLE](/apps/creating-github-apps/about-creating-github-apps/deciding-when-to-build-a-github-app#github-apps-offer-enhanced-security)."
-
 ### Pros of deploy keys
 
 * Anyone with access to the repository and server has the ability to deploy the project.
@@ -81,16 +79,10 @@ For enhanced security and fine-grained control over repository access and permis
 
 * Deploy keys only grant access to a single repository. More complex projects may have many repositories to pull to the same server.
 * Deploy keys are usually not protected by a passphrase, making the key easily accessible if the server is compromised.
-* Deploy keys are credentials that don't have an expiry date.
-* Deploy keys aren't linked directly to organization membership. If the user who created the deploy key is removed from the repository, the deploy key will still be active as it isn't tied to the specific user, but rather to the repository.
+* If the user who created the deploy key is removed from the repository, the deploy key will still be active as it isn't tied to the specific user, but rather to the repository.
 
 ### Set up deploy keys
 
-{% ifversion deploy-keys-enterprise-org-policy %}
-
-> [!NOTE] If your organization is owned by an enterprise, and your enterprise owner has restricted the use of deploy keys in repositories, then you cannot override the policy in your organization to create a deploy key. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-deploy-keys)."
-{% endif %}
-
 1. [Run the `ssh-keygen` procedure][generating-ssh-keys] on your server, and remember where you save the generated public and private rsa key pair.
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}

content/code-security/getting-started/best-practices-for-preventing-data-leaks-in-your-organization.md

@@ -52,9 +52,6 @@ Disable the ability to fork repositories. | "[AUTOTITLE](/repositories/managing-
 Disable changing repository visibility. | "[AUTOTITLE](/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization)"
 Restrict repository creation to private or internal. |  "[AUTOTITLE](/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization)"
 Disable repository deletion and transfer. | "[AUTOTITLE](/organizations/managing-organization-settings/setting-permissions-for-deleting-or-transferring-repositories)"
-| {% ifversion deploy-keys-enterprise-org-policy %} |
-Disable the ability to use deploy keys. | "[AUTOTITLE](/organizations/managing-organization-settings/restricting-deploy-keys-in-your-organization)"
-| {% endif %} |
 Scope {% data variables.product.pat_generic %}s to the minimum permissions necessary. | None
 Secure your code by converting public repositories to private whenever appropriate. You can alert the repository owners of this change automatically using a {% data variables.product.prodname_github_app %}. | [Prevent-Public-Repos](https://github.com/apps/prevent-public-repos) in {% data variables.product.prodname_marketplace %}
 Confirm your organization’s identity by verifying your domain and restricting email notifications to only verified email domains. | "[AUTOTITLE](/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization){% ifversion ghec or ghes %}" and "[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/restricting-email-notifications-for-your-organization){% endif %}"{% ifversion fpt or ghec %}

content/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/about-the-github-advisory-database.md

@@ -68,9 +68,7 @@ Our malware advisories are mostly about substitution attacks. During this type o
 
 ## About information in security advisories
 
-In this section, you can find more detailed information about security advisories in the {% data variables.product.prodname_advisory_database %}, such as:
-* Advisory IDs and what format these identifiers use.
-* The CVSS levels we used to assign severity levels.
+In this section, you can find more detailed information about specific data attributes of the {% data variables.product.prodname_advisory_database %}.
 
 ### About GHSA IDs
 
@@ -105,6 +103,25 @@ The {% data variables.product.prodname_advisory_database %} uses the CVSS levels
 
 {% data reusables.repositories.github-security-lab %}
 
+### About EPSS scores
+
+The Exploit Prediction Scoring System, or EPSS, is a system devised by the global Forum of Incident Response and Security Teams (FIRST) for quantifying the likelihood of vulnerability exploit. The model produces a probability score between 0 and 1 (0 and 100%), where the higher the score, the greater the probability that a vulnerability will be exploited. For more information about FIRST, see https://www.first.org/.
+
+The {% data variables.product.prodname_advisory_database %} includes EPSS scores from FIRST for advisories containing CVEs with corresponding EPSS data.  {% data variables.product.company_short %} also displays the EPSS score percentile, which is the proportion of all scored vulnerabilities with the same or a lower EPSS score.
+
+For example, if an advisory had an EPSS score that had a percentage of 90.534% at the 95th percentile, according to the [EPSS model](https://www.first.org/epss/model), this means that:
+
+* There is a 90.534% chance of this vulnerability being exploited in the wild in the next 30 days.
+* 95% of the total modeled vulnerabilities are considered less likely to be exploited in the next 30 days than this vulnerability.
+
+Extended information about how to interpret this data can be found in FIRST's EPSS User Guide. This information helps you understand how both percentage and percentile can be used to interpret the likelihood that a vulnerability could be exploited in the wild according to FIRST's model. For more information, see the [FIRST's EPSS User Guide](https://www.first.org/epss/user-guide) on the FIRST website.
+
+FIRST also provides additional information around the distribution of their EPSS data.  For more information, see [EPSS data and statistics documentation](https://www.first.org/epss/data_stats) on the FIRST website.
+
+>[!NOTE] {% data variables.product.company_short %} keeps EPSS data up to date with a daily synchronization action. While EPSS score percentages will always be fully synchronized, score percentiles will only be updated when significantly different.
+
+At {% data variables.product.company_short %}, we do not author this data, but rather source it from FIRST, which means that this data is not editable in community contributions.
+
 ## Further reading
 
 * "[AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)"

content/organizations/managing-organization-settings/index.md

@@ -31,7 +31,6 @@ children:
   - /enabling-or-disabling-github-discussions-for-an-organization
   - /managing-discussion-creation-for-repositories-in-your-organization
   - /managing-the-commit-signoff-policy-for-your-organization
-  - /restricting-deploy-keys-in-your-organization
   - /setting-team-creation-permissions-in-your-organization
   - /creating-an-announcement-banner-for-your-organization
   - /managing-scheduled-reminders-for-your-organization

content/rest/deploy-keys/deploy-keys.md

@@ -20,11 +20,6 @@ autogenerated: rest
 
 Deploy keys can either be set up using the following API endpoints, or by using the {% data variables.product.company_short %} web interface. To learn how to set deploy keys up in the web interface, see "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys)."
 
-{% ifversion deploy-keys-enterprise-org-policy %}
-
-You may be unable to create deploy keys if your organization or enterprise owner has set a policy to restrict their use. Furthermore, if this policy is enabled at the organization or enterprise level, existing deploy keys may be disabled. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-deploy-keys)" and "[AUTOTITLE](/organizations/managing-organization-settings/restricting-deploy-keys-in-your-organization)."
-{% endif %}
-
 There are a few cases when a deploy key will be deleted by other activity:
 
 * If the deploy key is created with a {% data variables.product.pat_generic %}, deleting the {% data variables.product.pat_generic %} will also delete the deploy key. Regenerating the {% data variables.product.pat_generic %} will not delete the deploy key.
@@ -36,6 +31,4 @@ Conversely, these activities will not delete a deploy key:
 * If the deploy key is created with a {% data variables.product.prodname_github_app %} installation access token, uninstalling or deleting the app will not delete the deploy key.
 * If the deploy key is created with a {% data variables.product.pat_generic %}, regenerating the {% data variables.product.pat_generic %} will not delete the deploy key.
 
-Changing this setting to disabled will result in existing deploy keys being disabled in all repositories in your enterprise.
-
 <!-- Content after this section is automatically generated -->

data/release-notes/enterprise-server/3-11/16.yml

@@ -0,0 +1,56 @@
+date: '2024-10-10'
+sections:
+  security_fixes:
+    - |
+      **MEDIUM**: Malicious URLs for SVG assets provided information about a victim user who clicked the URL, allowing an attacker to retrieve metadata belonging to the user and use it to generate a convincing phishing page. This required the attacker to upload malicious SVGs and phish a victim user to click the URL for the uploaded asset. This vulnerability was reported via the [GitHub Bug Bounty](https://bounty.github.com/) program.
+    - |
+      **HIGH**: An attacker could bypass SAML single sign-on (SSO) authentication with the optional encrypted assertions feature, allowing unauthorized provisioning of users and access to the instance, by exploiting an improper verification of cryptographic signatures vulnerability in GitHub Enterprise Server. This was a regression introduced as part of follow-up remediation from [CVE-2024-4985](https://www.cve.org/cverecord?id=CVE-2024-4985), which resulted in a new variant of the vulnerability. Please note that encrypted assertions are not enabled by default. Instances not utilizing SAML SSO, or utilizing SAML SSO authentication without encrypted assertions, are not impacted. Additionally, an attacker would require direct network access as well as a signed SAML response or metadata document. GitHub has requested CVE ID [CVE-2024-9487](https://www.cve.org/cverecord?id=CVE-2024-9487). This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com/).
+  bugs:
+    - |
+      HAProxy reloading was failure prone, which could lead to failed Git operations. This reloading process has been replaced with a more resilient Systemd process.
+    - |
+      An unhandled nil value when configuring Actions storage with AWS S3 via OIDC configuration in the terminal could cause an error.
+    - |
+      On an instance with secret scanning enabled, the custom pattern page would not load because dry run results were tied to a deleted repository.
+    - |
+      The "List teams" API endpoint returned duplicate results when paginating.
+    - |
+      A model with no URL could cause a `ghe-migrator` import to fail.
+    - |
+      Restore could fail when restoring MySQL using backup-utils.
+  changes:
+    - |
+      Pre-receive hook environments can use the `clone3()` system call.
+    - |
+      The creation, deletion, or change in visibility of a gist has been added to the audit log.
+  known_issues:
+    - |
+      Custom firewall rules are removed during the upgrade process.
+    - |
+      During the validation phase of a configuration run, a `No such object` error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.
+    - |
+      If the root site administrator is locked out of the Management Console after failed login attempts, the account does not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "[AUTOTITLE](/admin/configuration/administering-your-instance-from-the-management-console/troubleshooting-access-to-the-management-console#unlocking-the-root-site-administrator-account)."
+    - |
+      The `mbind: Operation not permitted` error in the `/var/log/mysql/mysql.err` file can be ignored. MySQL 8 does not gracefully handle when the `CAP_SYS_NICE` capability isn't required, and outputs an error instead of a warning.
+    - |
+      {% data reusables.release-notes.2023-11-aws-system-time %}
+    - |
+      On an instance with the HTTP `X-Forwarded-For` header configured for use behind a load balancer, all client IP addresses in the instance's audit log erroneously appear as 127.0.0.1.
+    - |
+      {% data reusables.release-notes.2023-10-git-push-made-but-not-registered %}
+    - |
+      {% data reusables.release-notes.large-adoc-files-issue %}
+    - |
+      {% data reusables.release-notes.2024-01-haproxy-upgrade-causing-increased-errors %}
+    - |
+      Repositories originally imported using `ghe-migrator` will not correctly track Advanced Security contributions.
+    - |
+      The `reply.[hostname]` subdomain is falsely always displaying as having no SSL and DNS record, when testing the domain settings via management console **without subdomain isolation**.
+    - |
+      The admin stats REST API endpoints may time out on appliances with many users or repositories. Retrying the request until data is returned is advised.
+    - |
+      {% data reusables.release-notes.2024-06-possible-frontend-5-minute-outage-during-hotpatch-upgrade %}
+    - |
+      When restoring from a backup snapshot, a large number of `mapper_parsing_exception` errors may be displayed.
+    - |
+      Services may respond with a `503` status due to an out of date `haproxy` configuration. This can usually be resolved with a `ghe-config-apply` run.