Enterprise Server 3.0 release notes

HIGH: A path traversal vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. User-controlled configuration options used by GitHub Pages were not sufficiently restricted and made it possible to read files on the GitHub Enterprise Server instance. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the GitHub Enterprise Server instance. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.1.8 and was fixed in 3.1.8, 3.0.16, and 2.22.22. This is the result of an incomplete fix for CVE-2021-22867. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2021-22868.

MEDIUM: An improper access control vulnerability in GitHub Enterprise Server allowed a workflow job to execute in a self-hosted runner group it should not have had access to. This affects customers using self-hosted runner groups for access control. A repository with access to one enterprise runner group could access all of the enterprise runner groups within the organization because of improper authentication checks during the request. This could cause code to be run unintentionally by the incorrect runner group. This vulnerability affected GitHub Enterprise Server versions from 3.0.0 to 3.0.15 and 3.1.0 to 3.1.7 and was fixed in 3.0.16 and 3.1.8 releases. It has been assigned CVE-2021-22869.

Resque worker counts were displayed incorrectly during maintenance mode.

Allocated memcached memory could be zero in clustering mode.

Packages have been updated to the latest security versions.

Attempting to tear down a newly-added replica node by specifying its UUID with ghe-repl-teardown would fail without reporting an error if replication was not started.

GitHub Pages builds were being passed through an external proxy if there was one configured.

Custom pre-receive hooks that created sub-processes would lack a PATH variable in their environment, resulting in "No such file or directory" errors.

MySQL could failover during an upgrade if mysql-auto-failover was enabled.

Packages have been updated to the latest security versions.

Attaching very large images or animated GIFs to images or pull requests would fail.

Journald messages related to automatic updates (Adding h/m/s random time.) were logged to syslog.

Custom pre-receive hooks that used a bash subshell would return an error: No such file or directory.

Custom pre-receive hooks that created named pipes (FIFOs) would crash or hang, resulting in a timeout error.

Adding filters to the audit log advanced search page did not populate the query text box in real-time with the correct facet prefix and value.

Git hooks to the internal API that result in failing requests returned the exception undefined method body for "success":String (NoMethodError) instead of returning an explicit nil.

When an integration was removed, it was possible for an unrelated OAuth application or integration to also be removed.

When a mandatory message containing an emoji character was added, attempting to view or change the message would return a 500 Internal Server Error.

When GitHub Actions is enabled without running regular scheduled backups the MSSQL Transaction Log could grow unbounded and can consume all available space on the appliance's Data Disk causing a possible outage.

Audit log entries for changes made to "Repository creation" organization settings were inaccurate.

Excessive logging of ActionController::UnknownFormat exceptions caused unnecessary disk usage.

LDAP group_dn values longer than 255 characters would result in errors being logged: Data truncated for column 'group_dn' at row 1.

Abuse rate limits are now called Secondary rate limits, since the behavior they limit is not always abusive.

Packages have been updated to the latest security versions.

Custom pre-receive hooks could lead to an error like error: object directory /data/user/repositories/0/nw/12/34/56/7890/network.git/objects does not exist; check .git/objects/info/alternates.

Unauthenticated HTTP proxy for the pages containers build was not supported for any users that use HTTP proxies.

A significant number of 503 errors were logged every time a user visited a repository''s /settings page if the dependency graph was not enabled.

Internal repositories were only returned when a user had affiliations with the repository through a team or through collaborator status, or queried with the ?type=internal parameter.

Failed background jobs had unlimited retries which could cause large queue depths.

A significant number of 503 errors were being created if the scheduled job to sync vulnerabilities with GitHub.com attempted to run when dependency graph was not enabled and content analysis was enabled.

The logs for babeld now include a cmd field for HTTP ref advertisement requests instead of only including it during the negotiation requests.

HIGH: A path traversal vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. User-controlled configuration options used by GitHub Pages were not sufficiently restricted and made it possible to read files on the GitHub Enterprise Server instance. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the GitHub Enterprise Server instance. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.1.3 and has been assigned CVE-2021-22867. This vulnerability was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

SAML expiration date variable was not configurable.

Application services would fail their health checks during config apply before they could enter a healthy state.

ghe-cluster-config-node-init would fail during cluster setup if HTTP proxy is enabled.

Pre-receive hooks could encounter an error Failed to resolve full path of the current executable due to /proc not being mounted on the container.

Collectd would not resolve the forwarding destination hostname after the initial startup.

The job that purged stale deleted repositories could fail to make progress if some of those repositories were protected from deletion by legal holds.

Running git nw-gc --pristine would result in an error.

Background jobs were being queued to the spam queue which were not being processed.

The preferred merge method would be reset when retrying after a failed PR merge.

Git pushes could result in a 500 Internal Server Error during the user reconciliation process on instances using LDAP authentication mode.

Improved the efficiency of config apply by skipping IP allow firewall rules that had not changed, which saved significant time on large clusters.

Packages have been updated to the latest security versions.

A large number of gauge-dependency-graph-api-dispatch_dispatch metrics could accumulate in the Management Console.

The sshd service would sometimes fail to start on instances running on Google Cloud Platform.

Old upgrade files would persist on the user disk, sometimes resulting in out of space conditions.

Log rotation could sometimes interrupt background jobs.

gh-migrator displayed an incorrect path to its log output.

An export archive would fail to import if it contained review requests from teams not present in the archive.

Packages have been updated to the latest security versions.

The upgrade process could fail while upgrading Actions if the instance could not make self-requests using its configured hostname.

SVN 1.7 and older clients showed an error when using the svn co and svn export commands.

Accessing a repository through the administrative shell using ghe-repo <owner>/<reponame> would hang.

After upgrading, users experienced reduced availability during heavy usage, because services restarted too frequently. This would occur due to timeout mismatches between the nomad configuration and that of the internal services.

In some instances, running ghe-repl-status after setting up GitHub Actions would produce an error and ghe-actions-teardown would fail.

ghe-dbconsole would return errors under some circumstances.

Import failures of organizations or repositories from non-GitHub sources could produce an undefined method '[]' for nil:NilClass error.

GitHub profile names might have changed unintentionally when using SAML authentication, if the GitHub profile name did not match the value of the attribute mapped to the Full name field in the Management Console.

The firstPatchedVersion field is now available on SecurityVulnerability objects in the GraphQL API.

Users of the GraphQL API can query the public field closingIssuesReferences on the PullRequest object. This field retrieves issues that will be automatically closed when the related pull request is merged. This approach will also allow this data to be migrated in future, as part of a higher fidelity migration process.

中：在某些情况下，从团队或组织中删除的用户可以保留对现有拉取请求打开的分支的写入权限。

包已更新到最新的安全版本。

在初始安装过程的“Configure Actions and Packages（配置 Actions 和 Packages）”页面，当管理员点击“Test domain settings（测试域设置）”按钮时，测试未完成。

运行 ghe-btop 失败，错误为 cannot find a 'babeld' container（找不到 'babeld' 容器）。

由于内部和外部超时值不匹配，用户在升级后无法获得服务。

MSSQL 中的正常复制延迟会生成警告。

GitHub Enterprise Clustering Guide 在管理控制台上的链接不正确。

管理员使用“Create Whitelist Entry（创建白名单条目）”按钮添加的 IP 地址仍可能被锁定。

未启用的仓库中显示了“依赖关系图”和“Dependabot 警报”功能的引用。

对 /hooks 端点的HTTP POST 请求可能会因为 hookID 设置不正确而失败，出现 401 响应。

build-server进程未能清理进程，将它们留在 defunct 状态下。

spond 创建了过多的日志条目，包括“修复位置已跳过”短语。

超过 4 个月的检查注释将存档。

高： 在 GitHub Enterprise Server 中发现了 UI 错误表述漏洞，允许在 GitHub 应用程序的用户授权网络流程期间授予比批准过程中显示给用户多的权限。要利用此漏洞，攻击者需要在实例上创建一个 GitHub 应用程序，用户需要通过 web 身份验证流程授权应用程序。所有授予的权限都将在第一次授权期间正确显示，但在某些情况下，如果用户在 GitHub 应用程序配置了额外的用户级权限后重新审查授权流程，这些额外的权限可能无法显示，导致授予的权限比用户潜在的预期要多。此漏洞会影响 3.0.7 之前的 GitHub Enterprise Server 3.0.x 和 2.22.13 之前的 2.22.x，在 3.0.7 和 2.22.13 版本中已修复。 已为此漏洞分配 CVE-2021-2286，并通过 GitHub Bug Bounty 计划 报告。

包已更新到最新的安全版本。

操作或包存储配置中包含的引号可能会导致错误。

由于文件大小或打开文件数量的限制过于严格，自定义预接收挂钩可能会失败。

在配置应用阶段可以启用 Orchestrator 自动故障转移。

具有仓库维护员权限的用户会收到电子邮件验证警告，而不是在仓库 Pages 设置页面上构建成功的页面。

通配符规则的代码所有者将被错误地添加到代码所有者徽章的所有者列表中，即使该路径优先使用较新的规则。

OpenAPI 文档引用了无效的标头。

在创建或编辑预接收挂钩时，用户界面中的竞争情况意味着在选择仓库后，仓库中的文件有时不会填充到文件下拉列表中。

添加了 HAProxy 重载时配置更改的日志记录。

添加了仓库创建的日志记录。

包已更新到最新的安全版本。

在升级过程中，进程将在 cleanup nomad job 之后无限期暂停。

ghe-cluster-failover 失败，出现错误消息 Trilogy::Error: trilogy_connect。

ghe-cluster-status-mysql 将有关故障转移的警告显示为错误。

在 MySQL 副本上运行的安装脚本可能导致数据库故障转移期间不必要的数据库重新播种。

升级未包括正确安装的 Actions 运行器最新版本。

github-env 配置可能导致僵尸进程。

由于不必要地调用 rake db:migrate，config-apply 可能需要更长的时间。

Orchestrator 可能已故障转移到 MySQL 副本，当主数据库无法连接时，它无法在播种阶段从主数据库复制。

出现错误的组织或项目阻止了迁移，无法排除。

对于所属组织超过 50 个的用户禁用了“Create Repository（创建仓库）”按钮。

删除分支会临时闪烁一条错误消息，指示删除成功时出错。

rms-packages 索引显示在站点管理员仪表板中。

由于表单上未显示正确的可见性选项，因此组织所有者无法创建内部仓库。

在操作启动工作流程配置错误的情况下，仓库操作选项卡显示 500。

由于选择了最完整的磁盘而不是空节点，存储主机超过三个的客户无法恢复到其灾难恢复集群。

应用热补丁后，代码扫描后端服务无法可靠启动。

默认情况下，预运行检查允许所有 AWS 实例类型。

包已更新到最新的安全版本。

有些日志未包含在日志转发配置中。

警告消息 jq: error (at <stdin>:0): Cannot index number with string "settings" 可能在副本升级期间出现。

由于 MySQL 副本无法连接到主数据库，因此将备份连续还原到集群可能会失败。

使用自定义 CA 证书时页面未发布。

与子域相关的包未显示在“测试域设置”提示中以进行子域隔离。

通过 web 挂钩发送的 X-GitHub-Enterprise-Host 标头包含一个随机字符串，而不是发送 HTTP POST 有效负载的 GitHub Enterprise Server 实例的主机名。

如果先前启用了 GitHub Actions，但在升级之前被禁用，则从 2.22.x 升级到 3.0.x 将会失败。

访问 /settings/email 页面会存储状态，在登出并重新登录时可能导致错误的重定向。

在议题评论中通过提及功能直接提及团队时，GitHub 集成应用程序无法通知团队。

restructuredText(RST) 渲染在 web 界面可能失败，反而显示原始 RST 标记文本。

如果未完全启用依赖项图，则不会将密码扫描警报的电子邮件通知发送给授权用户。

当 ghe-migrator 遇到导入错误时，它有时会中止整个过程，但日志中没有包含足够的上下文。

具有非 ASCII 字符的 Jupyter notebook 可能无法渲染。

高：在 GitHub 企业服务器中发现了一个不当的访问控制漏洞，该漏洞允许从 GitHub App 的 Web 身份验证流程 生成的访问令牌通过 REST API 读取专用仓库元数据，而无需获得适当的权限。要利用此漏洞，攻击者需要在实例上创建 GitHub 应用程序，并让用户通过 Web 身份验证流程授权应用程序。返回的私有仓库元数据将仅限于令牌标识的用户拥有的仓库。此漏洞影响了 GitHub Enterprise Server 3.0.4 之前的所有版本，但在 3.0.4、2.22.10、2.21.18 版本中已修复。此漏洞已分配 CVE-2021-22865，并通过 [GitHub Bug Bounty 计划]](https://bounty.github.com) 报告。

包已更新到最新的安全版本。

当启用维护模式时，某些服务仍然列为“活动进程”，尽管预计它们将运行， 并且不应该被列出。

在从 2.22.x 升级到启用 GitHub Actions 的 3.0.x 后，自托管运行器版本没有更新，也没有自托管更新。

旧 GitHub Pages 构建未进行清理，导致磁盘使用量增加。

memcached 未在活动的副本上运行。

启用 GitHub Actions 时更新文件权限失败。

在 GitHub Enterprise 11.10.x 或更早版本中设置的时区没有被一些默认使用 UTC 时间的服务使用。

服务未作为日志旋转的一部分而过渡到新的日志文件，导致磁盘使用量增加。

ghe-saml-mapping-csv 命令行实用生成了一条警告消息。

内部仓库搜索结果上的标签显示为“私有”而不是“内部”。

高：在 GitHub Enterprise Server 中发现了远程代码执行漏洞，可能在构建 GitHub Pages 站点时被利用。GitHub Pages 使用的用户控制配置选项没有受到足够的限制，因此可以覆盖导致在 GitHub Enterprise Server 实例上执行代码的环境变量。要利用此漏洞，攻击者需要获得在 GitHub Enterprise Server 实例上创建和构建 GitHub Pages 站点的权限。此漏洞影响 GitHub Enterprise Server 3.0.3 之前的所有版本，已在 3.0.3、2.22.9 和 2.21.17 中修复。此漏洞通过 GitHub Bug Bounty 计划报告，已分配 CVE-2021-22864。

包已更新到最新的安全版本。

运行 ghe-cluster-config-init 可能会使集群无法操作。

当自定义预接收挂钩配置在仓库上时，解析 GUI 中的合并冲突将失败。

launch-deplauncher 和 launch-recever 在DEBUG 级别记录日志，并且用不必要的信息填充日志。

系统可能会失去 HAProxy PID 的跟踪。

当 Actions 配置为使用 S3 存储时，操作的日志有时无法加载。

Mysql-failover 警告在成功故障转移后无限期显示。

ghe-cluster-config-init 运行未完全考虑背景作业的退出代码，导致印检查的处理不当。

启用 GitHub Actions 时，初始化可能会静默失败。

启用漏洞警报后，升级到 3.0 系列将失败。

与 Codespace 有关的作业在排队，导致未处理的作业累积。

即使有几个节点关闭，对 consul 和 nomad bootstrap_expect 使用相对编号也允许集群 bootstrap。

除时间外，日志还根据大小旋转。

添加 kafka lite 到 'ghe-cluster-status' 命令。

包已更新到最新的安全版本。

在备份过程中尝试清理可清除的存储对象时，出现了“Warning: One or more storage objects were not found on the source appliance.（警告：源设备上未找到一个或多个存储对象。）”的错误。

依赖关系图无法解析 yarn.lock JavaScript 清单文件，导致日志中的 HTTP 500 错误。

禁用 GitHub Actions 有时会失败。

自定义预接收挂钩不允许写入 /tmp，从而阻止某些脚本正常运行。

在多个地方复制了系统日志。

在 GitHub Enterprise 11.10.x 或更早版本上设置的时区在升级到 3 后被重置为 UTC 时间，导致时间戳在某些情况下改变。

单击仓库上包侧边栏中的“Publish your first package（发布您的第一个包）”将导致空白页面。

站点管理员在尝试查看从私有私有仓库引用的议题时可能会获得 500 错误页面。

禁用 GitHub Packages 后，一些组织页面会返回 HTTP 500 错误响应。

从 GitHub Enterprise Server 导入丢失的仓库文件将因错误而失败。

仓库部署密钥 无法用于包含 LFS 对象的仓库。

在仓库的软件包侧边栏中，Docker 图标是灰色的，工具提示显示“This service is deprecated（此服务已弃用）”。

使用 application/x-www-form-urlencoded 的内容类型配置的 web 挂钩在 POST 请求正文中没有接收查询参数。

用户无需选中所有复选框即可忽略强制消息。

在某些情况下，从 2.22.X 实例升级后，web 接口资源丢失，页面无法正常运行。

运行 ghe-config-apply 可能会超时，并且因“'job' stanza not found（找不到 stanza 作业）”而出现“Failure waiting for nomad jobs to apply（等待 nomad 作业应用失败）”。

高：在 GitHub Enterprise Server 中发现了一个不适当的访问控制漏洞，允许经过验证的实例用户通过特殊构建的拉取请求和 REST API 请求获得对未授权仓库的写入权限。攻击者需要能够复刻目标仓库，该设置默认为组织拥有的私有仓库禁用。分支保护（如所需的拉取请求审查或状态检查）将防止未经进一步审查或验证的未授权提交被合并。此漏洞已分配 CVE-2021-22861。这个问题是通过 GitHub Bug Bounty 计划 报告的。

高： GitHub Enterprise Server GraphQL API 中发现了一个不当的访问控制漏洞，允许经过验证的实例用户在未经适当授权的情况下修改拉取请求的维护者协作权限。通过利用此漏洞，攻击者将能够访问在其作为维护者的仓库上打开的拉取请求的头部分支。对于组织拥有的私有仓库，复刻默认为禁用，并将阻止此漏洞。此外，分支保护（如必需的拉取请求审查或状态检查）将防止未经进一步审查或验证的未授权提交被合并。此漏洞已分配 CVE-2021-22863。这个问题是通过 GitHub Bug Bounty 计划 报告的。

高：在 GitHub Enterprise Server 中发现了不当的访问控制漏洞，允许能够复刻仓库的经验证用户为复刻的父仓库披露 Actions 密钥。此漏洞的存在源于一个缺陷，该缺陷允许更新拉取请求的基础引用，以指向复刻仓库外部的任意 SHA 或其他拉取请求。通过在 PR 中建立此不正确的引用，可以绕过限制从复刻发送工作流程的 Actions 密钥的限制。此漏洞影响了 GitHub Enterprise Server 版本 3.0.0、3.0.0.rc2 和 3.0.0.rc1，并已分配 CVE-2021-22862。此漏洞是通过 GitHub Bug Bounty 计划报告的。

中：来自 GitHub Pages 建立号的 GitHub 令牌可能在日志中结束。

包已更新到最新的安全版本。

在某些情况下，负载平衡器健康检查可能导致 babld 日志充满有关代理协议的错误。

HTTP 标头在特定响应中不符合 HTTP RFC 标准，如 304 存档的状态。

在启用了依赖关系图功能的主机 Python 仓库的实例中，由于根盘中填充了错误日志，实例可能会变得无响应。

在 GitHub Enterprise 备份实用程序快照期间，信息消息被无意中记录为错误，这导致在备份由侦听输出到 stderr 的 cron 作业安排时发送不必要的电子邮件。

在 VMWare ESX 6.7 上，初始配置可能会在创建主机密钥时挂起，使实例无法通过 SSH 访问。

启用 GitHub Actions 时，在管理控制台中禁用维护模式失败。

包创建设置显示在组织成员设置页面上，但此功能尚不可用。

在 Security & Analysis（安全和分析）页面上启用密钥扫描时，对话框不正确地提及私有仓库。

在编辑 wiki 页面时，用户单击 Save（保存）按钮时可能会遇到 500 错误。

使用主题替代名称中具有多个名称的证书签名的 S/MIME 签名提交将错误地显示为提交徽章中的“未验证”。

用户在使用 LDAP 身份验证配置的实例上执行 git 操作时看到 500 错误。

被暂停的用户在添加到团队时收到电子邮件。

当仓库有大量清单时，在 Insights（见解）-> Dependency graph（依赖关系图）选项卡上显示错误 You have reached the maximum number of allowed manifest files (20) for this repository.（您已达到此存储库允许的清单文件的最大数量）。更多信息请参阅可视化限制。

即使存储库未启用 Actions，也可修复显示设置代码扫描代 CodeQL Action 选项的用户。

无法成功启用或禁用企业帐户设置中的“Prevent repository admins from changing anonymous Git read access（防止仓库管理员更改匿名 Git 读取访问权限）”复选框。

用于显示强制消息的模组不包含垂直滚动栏，这意味着无法完全查看较长的消息。

Redis 有时在硬重启或应用程序崩溃后无法启动。

依赖关系图无法解析 setup.py Python 清单文件，导致日志中的 HTTP 500 错误。 这种情况再加上重复的记录问题，导致根卷的使用增加。

当多个用户下载同一存档时，可同时满足请求，从而提高性能。

高：在 GitHub Enterprise Server 中发现了远程代码执行漏洞，可能在构建 GitHub Pages 站点时被利用。GitHub Pages 使用的基础解析器的用户控制配置没有受到足够的限制，因此可以在 GitHub Enterprise Server 实例上执行命令。要利用此漏洞，攻击者需要获得在 GitHub Enterprise Server 实例上创建和构建 GitHub Pages 站点的权限。此漏洞已分配 CVE-2020-10519，并通过 GitHub Bug Bounty 计划 报告。

GitHub Actions 现在一般在 GitHub Enterprise Server 3.0+ 上提供。从 GitHub 构建、测试和部署您的代码。以您希望的方式提交代码审核、分支管理和议题分类工作。

此发行版与 GitHub Enterprise ServerGitHub Actions 测试版相比有几项改进：

• 企业、组织和仓库管理员可以创建安全策略，以在 GitHub.com 上访问 GitHub Actions 。
• 企业、组织和仓库管理员可以允许公共仓库使用自托管的运行器。
• 企业、组织和仓库管理员现在可以允许工作流程在产生自私有仓库复刻的拉取请求上运行。
• workflow_run 事件现在受支持
• 用户现在能够禁用工作流程并在以后启用它们。
• 工作流日志得到了增强，以获得更好的用户体验。
• 用户现在可以在容器作业和服务中使用私有映像。
• 工件和日志的最大保留天数现在可以自定义。
• 运行器组 API 现在包括 labels。
• 您现在可以使用 shell 脚本结合组成运行步骤创建可重复使用的操作。
• 组织的加密机密 允许您跨仓库合并机密。
• 组织的工作流程模板 简化并促进整个组织的最佳实践和一致性。

目前不支持使用集群配置的企业使用 GitHub Actions。

GitHub Packages 是一项包托管服务，原生集成 GitHub ABI、Actions 和 web 挂钩。创建端到端 DevOps 工作流程 ，其中包括您的代码、持续集成和部署解决方案。

支持的存储后端包括 AWS S3 和 MinIO，支持未来版本中的 Azure blob。请注意，当前的 Docker 支持将在下一个版本中替换为新 GitHub Container Registry 的测试版。在打开 GitHub Packages 之前，请查看平台更新的最低要求。

将软件包发布到 NuGet 时，用户现在可以使用 --api-key 选项来传递其身份验证令牌，而不是将其写入文件。更多信息请参阅配置 dotnet CLI 用于GitHub Packages

GitHub Packages 目前不支持使用集群配置的企业。

手机版 GitHub 测试版允许您对通知进行分类，以及从设备管理议题和提取请求。您可以同时使用 GitHub.com 上的一个用户帐户以及 GitHub Enterprise Server 上的一个用户帐户登录到移动设备。

手机版 GitHub 测试版现在可用于 GitHub Enterprise Server。使用我们的 Android 和 iOS app 登录，以随时对通知分类以及管理议题和拉取请求。管理员可以使用管理控制台或运行 ghe-config app.mobile.enabled false 来禁用对其企业的移动支持。

机密扫描测试版 扫描公共和私有仓库以查找提交的凭据，查找机密，并在机密提供商或管理员提交到仓库时通知他们。

使用 GitHub Advanced Security 的管理员可以启用和配置 GitHub Advanced Security 机密扫描。在打开 GitHub Advanced Security 机密扫描之前，您可以查看更新的平台最低要求。

GitHub Advanced Security 代码扫描 现在一般可用于 GitHub Enterprise Server。购买了 Advanced Security 的组织可以利用此功能对其代码进行静态分析安全测试，并防止漏洞使用我们的语义分析引擎 CodeQL 将其变成生产代码。更多信息请参阅“在设备上配置代码扫描”

Web 挂钩事件传输系统已被新设计，以提高传输量、加快传送速度和减少延迟消息。它还在 GitHub Enterprise Server 3.0+ 中使用较少的 CPU 和内存。

组织和企业所有者现在可以通过新的 team.promote_maintainer 和 team.demote_maintainer 审核日志事件查看团队成员何时被提升为或降级为审核日志中的团队维护者。更多信息请参阅“已审核的操作”。

现有 GitHub Pages 站点的仓库维护员可以轻松更新其以前的默认分支名称。

需要额外的硬件资源才能运行启用了任何 Actions、Packages 或 Advanced Security 的 GitHub Enterprise Server。有关每个支持平台所需的最低资源的更多信息，请参阅“设置 GitHub Enterprise Server 实例”。

管理员现在可以[发布消息](/enterprise-server@3.0/admin/user-management/customizing-user-messages-for your enter-enterprises)，所有用户都必须接受。这可以帮助登记新用户以及显示其他组织特定的信息和政策。

组织所有者现在可以禁用从组织仓库发布 GitHub Pages 站点。对组织禁用 GitHub Pages 将阻止成员创建新的 Pages 站点，但不会取消发布现有站点。更多信息请参阅“对组织禁用发布 GitHub Pages 站点”。

在启用活动副本之前，必须在所有节点上明确定义数据中心。

SSH 指纹的所有使用都已切换到使用 SHA256 指纹，因为自版本 6.8 以来，它们也与 OpenSSH 一起使用。这适用于 Web 界面和以及其中返回指纹（如在 GraphQL 中）的 API。指纹遵循 OpenSSH 格式。

在 web 挂钩上发送 SHA-1 和 SHA-256 签名标头（两个标头）。

GitHub Enterprise Server 3.0+ 中运行的大部分服务现在都位于容器上，这些容器内部使 GitHub 能够快速迭代并运送高质量的版本

Web 挂钩事件传输系统已重新设计，以提高传输量、加快传送速度和减少延迟消息。

管理员现在可以通过 REST API 配置和管理整个站点的公告横幅。更多信息请参阅“GitHub Enterprise 管理”的端点。

新的 API 端点可让用户交换服务器令牌，以将令牌范围限于特定仓库。更多信息请参阅 GitHub REST API 文档中的“Apps”。

企业和组织管理员现在可以设置新仓库的默认分支名称。企业管理员也可以在所有组织强制执行其默认分支名称的选择，或允许个别组织选择自己的分支名称。

现有仓库不受这些设置的影响，其默认分支名称不会更改。

此更改是 GitHub 为了支持那些想重命名其默认分支的项目和维护者。 要了解更多关于我们正在进行的更改，请参阅 github/renaming。

除“已知问题”部分所列问题外，候选版 1 和候选版 2 中的所有已知问题均已解决。

迁移和升级到 3.0.0 的问题已经修复。

备份实用程序版本现在适用于候选版本。

生成支持包导致编组日志中出现错误。

大型还原可能导致 Redis 内存耗尽。

现在，使用任何身份验证方法都可以看到管理控制台中启用 GitHub Actions 的复选框。

仅在配置了所需存储时才可启用 GitHub Actions。

如果未配置 MSSQL 复制，ghe-repl-status 可能会失败而不出现提示。

几个日志文件的格式已经改变，包括为不同的日志类型添加 PID。这不影响 GitHub Enterprise Support 如何使用支持包解决故障问题。

对 web 挂钩配置 API 的 PATCH 请求不再清除 web 挂钩机密。

某些类型的预接收挂钩失败。

Packages Nuget 服务目前在发布时实现语义版本正常化。无效的语义版本（例如：v1.0.0.0.0.0）无法被 Nuget 客户端下载，因此 Nuget 服务需要正常化这些版本（例如： v1.0.0.0.0.0 --> v1.0.0）。任何原始的非正常化版本将在 verbatimVersion 字段中可用。无需更改客户端配置。

在新建的没有任何用户的 GitHub Enterprise Server 上，攻击者可以创建第一个管理员用户。

自定义防火墙规则在升级期间不会保持。

Git LFS 跟踪的文件通过 Web 界面上传 被错误地直接添加到仓库。

对 GitHub Connect 启用“用户可以搜索 GitHub.com”后，私有和内部仓库中的议题不包括在 GitHub.com 搜索结果中。

当启用维护模式时，某些服务将继续列为“活动进程”。 指定的服务预期在维护模式下运行。如果您遇到这个问题但不确定，请联系 GitHub Enterprise 支持 或 GitHub 高级支持。

当 GitHub Actions 启用时，使用 'ghe-maintenance -u' 来取消维护模式。

重复记录到 /var/log/messages、/var/log/syslog 和 /var/log/user.log 将提高根卷利用率。

用户无需选中所有复选框即可忽略强制消息。

预接收挂钩脚本 无法编写临时文件，这可能导致脚本执行失败。使用预接收挂钩的用户应在暂存环境中进行测试，以查看脚本是否需要写入权限。

仓库部署密钥 无法用于包含 LFS 对象的仓库。

如果笔记本包含非 ASCII UTF-8 字符，网页界面中的 Jupyter Notebook 渲染可能会失败。

restructuredText(RST) 渲染在 web 界面可能失败，反而显示原始 RST 标记文本。

依赖关系图无法解析 setup.py Python 清单文件，导致日志中的 HTTP 500 错误。 这种情况再加上重复的记录问题，导致根卷的使用增加。

竞争条件可能导致依赖关系图数据库迁移失败。

自定义时区从较早发布的 GitHub Enterprise Server 升级的实例可能在 web UI 中有不正确的时间戳。

Pages 的旧版本未清理，可能填充用户磁盘 (/data/user/)。

在合并拉取请求后删除分支时，即使分支删除成功也会出现错误消息。

When a replica node is offline in a high availability configuration, GitHub Enterprise Server may still route GitHub Pages requests to the offline node, reducing the availability of GitHub Pages for users.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

*GitHub Enterprise Server 2.19 自 2020 年 11 月 12 日起弃用。这意味着在此日期之后，即使对于关键的安全问题，也不会发布修补程序。为获得更好的性能、更高的安全性和新功能，请尽快升级到最新版本的 GitHub Enterprise Server。

从 GitHub Enterprise Server 2.21.0 开始，两个旧的 GitHub 应用程序相关的 web 挂钩事件已弃用，并将在 GitHub Enterprise Server 3.2.0 中删除。弃用的事件 integration_installation 和 integration_installation_repositories 都有受支持的相应事件。更多信息请见弃用公告博文。

从 GitHub Enterprise Server 2.21.0 开始，用于创建安装访问令牌的旧 GitHub 应用程序端点已弃用，并将在 GitHub Enterprise Server 3.2.0 中删除。更多信息请见弃用公告博文。

GitHub 不再支持包含 access_token 作为路径参数的 OAuth 应用程序端点。我们引入了新的端点，允许您通过将 access_token 移动到请求正文来安全地管理 OAuth 应用程序的令牌。虽然已弃用，但这些端点仍然可以在这个版本中访问。我们打算在 GitHub Enterprise Server 3.4 中删除这些端点。更多信息请参阅弃用公告博文。

在未广泛使用的拉请求视图中，服务支持“用符号查找”体验。

GitHub Actions set-env 和 add-path 工作流程命令已弃用。更多信息请参阅 changelog。