Enterprise Server 3.2 release notes

HIGH: Updated dependencies for the Management Console to the latest patch versions, which addresses security vulnerabilities including CVE-2022-30123 and CVE-2022-29181.

HIGH: Added checks to address an improper cache key vulnerability that allowed an unauthorized actor to access private repository files through a public repository. This vulnerability has been assigned CVE-2022-23738.

MEDIUM: Updated CommonMarker to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned CVE-2022-39209.

LOW: Due to a CSRF vulnerability, a GET request to the instance's site/toggle_site_admin_and_employee_status endpoint could toggle a user's site administrator status unknowingly.

After a site administrator installed a hotpatch containing changes to web interface assets such as JavaScript files or images, the instance did not serve the new assets.

HIGH: A GitHub App could use a scoped user-to-server token to bypass user authorization logic and escalate privileges.

MEDIUM: The use of a Unicode right-to-left override character in the list of accessible files for a GitHub App could obscure additional files that the app could access.

Packages have been updated to the latest security versions.

In a cluster configuration, running ghe-cluster-config-apply could cause unconfigured nodes to replicate configuration to the rest of the cluster, potentially removing configurations from existing nodes.

In some cases, the Management Console's monitor dashboard would not load correctly.

When sending a support bundle to GitHub Enterprise Support using ghe-support-upload, the -t option would not successfully associate the uploaded bundle with the specified ticket.

After a user deleted or restored packages from the web interface, counts for packages could render incorrectly.

Manually disabled GitHub Actions workflows in a repository were re-enabled if the repository received a push containing more than 2048 commits, or if the repository's default branch changed.

When using a VPC endpoint URL as an AWS S3 URL for GitHub Packages, publication and installation of packages failed.

Chaves SSH administrativas duplicadas podem aparecer tanto no Console de Gerenciamento quanto no arquivo /home/admin/.ssh/authorized_keys.

Em alguns casos, as tarefas em segundo plano podem parar devido a uma biblioteca que foi usada simultaneamente, apesar de não ser thread-safe.

A geração de pacotes de suporte é mais rápida como resultado da sanitização de log paralelizada. Para ver mais informações sobre pacotes de suporte, confira "Como fornecer dados ao suporte do GitHub."

CRITICAL: GitHub Enterprise Server's Elasticsearch container used a version of OpenJDK 8 that was vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. The vulnerability is tracked as CVE-2022-34169.

HIGH: Previously installed apps on user accounts were automatically granted permission to access an organization on scoped access tokens after the user account was transformed into an organization account. This vulnerability was reported via the GitHub Bug Bounty program.

When a custom dormancy threshold was set for the instance, suspending all dormant users did not reliably respect the threshold. For more information about dormancy, see "Managing dormant users."

MÉDIO: evita um ataque em que uma SSRF (falsificação de solicitação do lado do servidor) poderia forçar a ponte SVN (Subversion) a executar código remoto injetando dados arbitrários no Memcached.

Atualiza o Grafana para a versão 7.5.16, que aborda várias vulnerabilidades de segurança, incluindo CVE-2020-13379 and CVE-2022-21702.

Os pacotes foram atualizados para as últimas versões de segurança.

MEDIUM: A vulnerability involving deserialization of untrusted data was identified in GitHub Enterprise Server that could potentially lead to remote code execution on the Subversion (SVN) bridge. To exploit this vulnerability, an attacker would need to gain access via a server-side request forgery (SSRF) that would let an attacker control the data being deserialized. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2022-23734.

Correção de um problema em que os arquivos dentro dos arquivos zip do artefato tinham permissões de 000 quando descompactados usando uma ferramenta de descompactação. Agora os arquivos terão as permissões definidas para 644, da mesma forma que funciona no GitHub.com.

Em alguns casos, o daemon collectd pode consumir memória em excesso.

Em alguns casos, os backups de arquivos de log rotacionados podem acumular e consumir armazenamento em excesso.

Após uma atualização para uma nova versão de recurso e execução de configuração subsequente, o Elasticsearch pode registrar exceções excessivas durante a reconstrução de índices.

Em alguns casos em que um branch protegido exigia mais de uma revisão de aprovação, uma solicitação de pull pode ser mesclada com um número menor que o necessário de revisões de aprovação.

Em instâncias que usam a autenticação LDAP, o prompt de autenticação para o modo sudo colocou incorretamente o cursor no campo de senha por padrão quando os campos de texto para nome de usuário e senha estavam visíveis.

O utilitário de linha de comando ghe-set-password inicia os serviços necessários automaticamente quando a instância é inicializada no modo de recuperação.

Métricas para processos em segundo plano aqueduct são reunidas para encaminhamento e exibição de Collectd no Console de Gerenciamento.

A localização do log de execução de configuração e migração do banco de dados, /data/user/common/ghe-config.log, agora é exibida na página que detalha uma migração em andamento.

MÉDIO: garante que github.company.com e github-company.com não sejam avaliados por serviços internos como nomes de host idênticos, evitando um possível ataque de SSRF (falsificação de segurança do lado do servidor).

BAIXO: um invasor pode acessar o Console de gerenciamento com um ataque de passagem de caminho via HTTP, mesmo que regras de firewall externas bloqueiem o acesso HTTP.

Os pacotes foram atualizados para as últimas versões de segurança.

Em alguns casos, os administradores do site não foram adicionados automaticamente como proprietários da empresa.

Depois de mesclar um branch a um branch padrão, o link "Histórico" de um arquivo ainda será vinculado ao branch anterior em vez do de destino.

A criação ou atualização de execuções de verificação ou conjuntos de verificação poderá retornar 500 Internal Server Error se o valor de determinados campos, como o nome, for muito longo.

Packages have been updated to the latest security versions.

An internal script to validate hostnames in the GitHub Enterprise Server configuration file would return an error if the hostname string started with a "." (period character).

In HA configurations where the primary node's hostname was longer than 60 characters, MySQL would fail to be configured.

The --gateway argument was added to the ghe-setup-network command, to allow passing the gateway address when configuring network settings using the command line.

Image attachments that were deleted would return a 500 Internal Server Error instead of a 404 Not Found error.

The calculation of "maximum committers across entire instance" reported in the site admin dashboard was incorrect.

An incorrect database entry for repository replicas caused database corruption when performing a restore using GitHub Enterprise Server Backup Utilities.

Optimised the inclusion of metrics when generating a cluster support bundle.

In HA configurations where Elasticsearch reported a valid yellow status, changes introduced in a previous fix would block the ghe-repl-stop command and not allow replication to be stopped. Using ghe-repo-stop --force will now force Elasticsearch to stop when the service is in a normal or valid yellow status.

MEDIUM: A security issue in nginx resolver was identified, where an attacker who could forge UDP packets from the DNS server could cause 1-byte memory overwrite, resulting in worker process crashes or other potentially damaging impacts. The vulnerability has been assigned CVE-2021-23017.

Updated the actions/checkout@v2 and actions/checkout@v3 actions to address new vulnerabilities announced in the Git security enforcement blog post.

Packages have been updated to the latest security versions.

In some cluster topologies, the ghe-cluster-status command left behind empty directories in /tmp.

SNMP incorrectly logged a high number of Cannot statfs error messages to syslog.

For instances configured with SAML authentication and built-in fallback enabled, built-in users would get stuck in a “login” loop when attempting to sign in from the page generated after logging out.

Videos uploaded to issue comments would not be rendered properly.

When using SAML encrypted assertions, some assertions were not correctly marking SSH keys as verified.

When using ghe-migrator, a migration would fail to import video file attachments in issues and pull requests.

The Releases page would return a 500 error when the repository has tags that contain non-ASCII characters. [Updated: 2022-06-10]

In high availability configurations, clarify that the replication overview page in the Management Console only displays the current replication configuration, not the current replication status.

When enabling GitHub Packages, clarify that using a Shared Access Signature (SAS) token as connection string is not currently supported.

Support bundles now include the row count of tables stored in MySQL.

Dependency Graph can now be enabled without vulnerability data, allowing you to see what dependencies are in use and at what versions. Enabling Dependency Graph without enabling GitHub Connect will not provide vulnerability information.

Packages have been updated to the latest security versions.

Upgrading the nodes in a high availability pair with an upgrade package could cause Elasticsearch to enter an inconsistent state in some cases.

In some cluster topologies, the command line utilities ghe-spokesctl and ghe-btop failed to run.

Elasticsearch indices could be duplicated during a package upgrade, due to an elasticsearch-upgrade service running multiple times in parallel.

When converting a user account to an organization, if the user account was an owner of the GitHub Enterprise Server enterprise account, the converted organization would incorrectly appear in the enterprise owner list.

Creating an impersonation OAuth token using the Enterprise Administration REST API worked incorrectly when an integration matching the OAuth Application ID already existed.

Configuration errors that halt a config apply run are now output to the terminal in addition to the configuration log.

When attempting to cache a value larger than the maximum allowed in Memcached, an error was raised however the key was not reported.

The CodeQL starter workflow no longer errors even if the default token permissions for GitHub Actions are not used.

If GitHub Advanced Security features are enabled on your instance, the performance of background jobs has improved when processing batches for repository contributions.

MÉDIO: Foi identificada uma vulnerabilidade transversal de caminho no console de gerenciamento GitHub Enterprise Server que permitiu o bypass de proteções CSRF. Essa vulnerabilidade afetou todas as versões de GitHub Enterprise Server anteriores �  3.5 e foi corrigida nas versões 3.1.19, 3.2.11, 3.3.6 e 3.4.1. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs de GitHub e foi designada como CVE-2022-23732.

MÉDIO: Foi identifica uma vulnerabilidade de estouro de número inteiro no branch 1.x e no branch 2.x de yajil que levava ao subsequente corrompimento de memória heap ao lidar com entradas grandes (~2GB). Essa vulnerabilidade foi relatada internamente e foi designada como CVE-2022-24795.

Pacotes de suporte poderiam incluir arquivos confidenciais, se GitHub Actions estivesse habilitado.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Os processos Minio teriam alto uso de CPU, se uma opção antiga de configuração estivesse presente após atualizar GitHub Enterprise Server.

As opções para habilitar TLS 1.0 e TLS 1.1 nas configurações de privacidade do console de gerenciamento foram mostradas, embora a remoção dessas versões de protocolo tenha ocorrido em uma versão anterior.

Em um ambiente HA, configurar a replicação MSSQL poderia exigir etapas manuais adicionais após habilitar GitHub Actions pela primeira vez.

Um subconjunto de arquivos de configuração internos são atualizados de modo mais confiável após um patch dinâmico.

O script ghe-run-migrations � s vezes falharia em gerar corretamente nomes de certificados temporários.

Em um ambiente de cluster, as operações do Git LFS poderiam falhar com chamadas �  API internas com falha que cruzaram inúmeros nós da web.

Ganchos de pré-recebimento que usaram gpg --import atingiram o tempo limite devido a privilégios syscall insuficientes.

Em algumas topologias de cluster, a informação de entrega de webhook não estava disponível.

Em configurações HA, subdividir uma réplica falharia se GitHub Actions tivesse sido habilitado anteriormente.

As verificações de integridade do Elasticsearch não permitiriam um status de cluster amarelo ao executar migrações.

As organizações criadas como resultado de um usuário transformando sua conta de usuário em uma organização não foram adicionadas �  conta global da corporação.

Ao usar ghe-migrator ou exportar de GitHub.com, uma exportação de execução longa falharia quando os dados fossem excluídos durante a exportação.

O grafo de implantação GitHub Actions exibiria um erro ao renderizar um trabalho pendente.

Foram removidos os links para páginas inacessíveis.

Sair de uma comparação de duas confirmações na interface do usuário da web teria o diff persistindo em outras páginas.

Acrescentar uma equipe como revisora de uma solicitação de pull � s vezes mostraria o número incorreto de membros daquela equipe.

O ponto de extremidade de API Remover associação de equipe para um usuário responderia com um erro ao tentar remover um membro gerenciado externamente por um grupo SCIM.

Um número grande de usuários inativos poderia causar falhas em uma configuração de GitHub Connect.

A página "Recurso e inscrição beta" na interface do usuário da web da página do administrador estava incorretamente disponível.

O link "Modo admin do site" no rodapé do site não mudou de estado quando clicado.

O comando spokesctl cache-policy rm não falha mais com a mensagem error: failed to delete cache policy.

Os limites de conexão armazenados no cache foram aumentados para acomodar melhor as topologias de cluster grande.

A API do grafo de dependência anteriormente era executada com uma porta estaticamente definida.

As contagens do fragmento padrão para as configurações de fragmentos do Elasticsearch relacionadas ao cluster foram atualizadas.

As funções de equipe “Triagem” e “Manutenção” são preservadas durante as migrações do repositório.

O desempenho foi melhorado para solicitações de web feitas por proprietários de corporações.

ALTO: Foi identificada uma vulnerabilidade de estouro de número inteiro no analisador markdown do GitHub que poderia levar a vazamentos de informações e RCE. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub por Felix Wilhelm do Project Zero da Google e foi designada CVE-2022-24724.

As atualizações podem � s vezes falhar se o relógio de uma réplica de alta disponibilidade estiver fora de sincroniza com o relógio principal.

Aplicativos OAuth criados após 1º de setembro, 2020 não puderam de usar o Ponto de extremidade API Verificar uma Autorização.

Foi possível para um usuário registrar um usuário ou organização denominado "saml".

Os pacotes foram atualizados para as últimas versões de segurança.

As configurações de armazenamento de pacotes do GitHub não puderam ser validadas e salvas no Console de Gerenciamento quando o Armazenamento de Blobs do Azure foi usado.

A opção de configuração mssql.backup.cadence falhou no ghe-config-check com um alerta de conjunto de caracteres inválido.

Corrige SystemStackError (stack muito profundo) ao obter mais de 2^{^16} chaves de memcached.

A verificação de segredo ignora a verificação ZIP e outros arquivos de segredos.

Os pacotes foram atualizados para as últimas versões de segurança.

As páginas ficariam indisponíveis após uma rotação do segredo do MySQL até que o nginx fosse reiniciado manualmente.

As migrações poderiam falhar quando GitHub Actions era habilitado.

Ao definir a agenda de manutenção com uma data da ISO 8601, o horário programado real não corresponderá devido ao fuso horário não ser convertido em UTC.

As mensagens de erro falsas sobre o arquivo cloud-config.service seriam a saída para o console.

O número da versão não poderia ser atualizado corretamente após a instalação de um patch dinâmico que usa ghe-cluster-each.

Trabalhos de limpeza na tabela de webhook podem ser executados simultaneamente, causando contenção de recursos e aumentando o tempo de execução do trabalho.

Quando executado por meio do primário, o ghe-repl-teardown em uma réplica não a remove do grupo de disponibilidade do MSSQL.

Ao usar a autenticação CAS com a opção "Reativar usuários suspensos", os usuários suspensos não eram reativados automaticamente.

A capacidade de limitar notificações com base em email para usuários com emails em um domínio verificado ou aprovado não funcionou corretamente.

Uma migração de execução longa do banco de dados relacionada � s configurações de alerta de segurança pode atrasar a conclusão da atualização.

O registro de conexão de dados do GitHub Connect agora inclui uma contagem do número de usuários ativos e inativos e o período de inatividade configurado.

Os pacotes foram atualizados para as últimas versões de segurança. Nestas atualizações, Log4j foi atualizado para a versão 2.17.1. Observe: mitigações anteriores nas versões 3.3.1, 3.2.6, 3.1.14 e 3.0.22 são suficientes para abordar o impacto de CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 e CVE-2021-44832 nestas versões do GitHub Enterprise Server.

Higienize mais segredos nos pacotes de suporte gerados

Os pacotes foram atualizados para as últimas versões de segurança.

Os executores auto-hospedados das ações falhavam ao realizar a própria atualização ou executar novos trabalhos após a atualização a partir de uma instalação antiga do GHES.

Não foi possível validar as configurações de armazenamento no momento da configuração de MinIO como armazenamento blobs para pacotes do GitHub.

Às vezes pode ocorrer uma falha ao executar ghe-config-apply devido a problemas de permissão em /data/user/tmp/pages.

O botão salvar no console de gerenciamento não era acessível usando a barra de rolagem nos navegadores de baixa resolução.

Grafos de monitoramento de tráfego de armazenamento e IOPS e não foram atualizados após a atualização de versão do collectd.

Alguns trabalhos relacionados ao Webhook poderiam gerar uma grande quantidade de registros.

Vários links de documentação geraram um erro 404 Not Found error.

Crítico: uma vulnerabilidade de execução de código remoto na biblioteca Log4j, identificada como CVE-2021-44228, afetou todas as versões de GitHub Enterprise Server anteriores �  3.3.1. A biblioteca Log4j é usada em um serviço de código aberto sendo executado na instância GitHub Enterprise Server. Essa vulnerabilidade foi corrigida nas versões GitHub Enterprise Server 3.0.22, 3.1.14, 3.2.6 e 3.3.1. Para ver mais informações, confira esta postagem no Blog do GitHub.

Atualização de 17 de dezembro de 2021: as correções nesta versão também mitigam CVE-2021-45046 que foi publicada após esta versão. Não é necessária nenhuma atualização adicional para GitHub Enterprise Server mitigar tanto CVE-2021-44228 como CVE-2021-45046.

Os pacotes de apoio podem incluir ficheiros sensíveis, caso satisfaçam um conjunto específico de condições.

Foi identificada uma vulnerabilidade de falsa representação da interface do usuário no GitHub Enterprise Server que permitia que mais permissões fossem concedidas durante o fluxo de autorização da Web de usuário do aplicativo do GitHub do que eram exibidas para o usuário durante a aprovação. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server anteriores �  3.3 e foi corrigida nas versões 3.2.5, 3.1.13, 3.0.21. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e foi designada CVE-2021-41598.

Foi identificada uma vulnerabilidade de execução de código remoto no GitHub Enterprise Server que poderia ser explorada ao compilar um site GitHub Pages. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server anteriores �  3.3 e foi corrigida nas versões 3.0.21, 3.1.13, 3.2.5. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e foi designada CVE-2021-41599. Atualização: 17 de fevereiro de 2022.

Em alguns casos quando o Ações não era habilitado, o ghe-support-bundle informava uma mensagem inesperada Não foi possível encontrar o contêiner MS SQL.

Às vezes pode ocorrer uma falha ao executar ghe-config-apply devido a problemas de permissão em /data/user/tmp/pages.

Uma configuração incorreta no Console de gerenciamento gerou erros de agendamento.

Os arquivos de registro do Docker eram mantidos abertos após a rotação de um registro.

As migrações podem ficar presas devido �  manipulação incorreta de valores blob_path não compatíveis com UTF-8.

As solicitações do GraphQL não definiram a variável GITHUB_USER_IP em ambientes de hook pre-receive.

Os links de paginação nos logs de auditoria de organização não continuavam com os parâmetros de consulta.

Durante um hotpatch, era possível duplicar hashes se uma transição ocorresse mais de uma vez.

Detalha a explicação do estilo caminho do Ação na documentação do caminho-estilo.

Atualiza as URLs de contato para usar o site support.github.com de suporte atual.

Solução de problemas adicional fornecida ao executar ghe-mssql-diagnostic.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Executar "ghe-repl-start" ou "ghe-repl-status" � s vezes poderia retornar erros conectados ao banco de dados quando o GitHub Actions foi habilitado.

Os ganchos de pré-recebimento falhariam devido a um "PATH" indefinido.

A execução de "ghe-repl-setup" retornaria o erro: "não foi possível criar diretório/dados/usário/elasticsearch: o arquivo já existe" caso a instância tenha sido configurada anteriormente como uma réplica.

Executar "ghe-support-bundle" retornou um erro: "expressão de inteiro esperada".

Após configurar uma réplica de alta disponibilidade, o "ghe-repl-status" incluiu um erro na saída: "ação não fechada inesperada no comando".

Em ambientes de grandes clusters, o back-end de autenticação pode estar indisponível em um subconjunto de nós do front-end.

Alguns serviços críticos podem não estar disponíveis em nós de back-end do Cluster do GHES.

As permissões do repositório para o usuário retornado pela API "/repos" não retornariam a lista completa.

A conexão "childTeam" no objeto "Team" do esquema GraphQL produziu resultados incorretos em algumas circunstâncias.

Em uma configuração de alta disponibilidade, a manutenção de repositório sempre informou falha em stafftools, mesmo quando foi bem-sucedida.

Os padrões definidos pelo usuário não detectariam segredos em arquivos como "package.json" ou "yarn.lock".

Uma camada externa adicional de compactação "gzip" ao criar um pacote de suporte de grupo com "ghe-cluster-suport-bundle" agora está desabilitada por padrão. Esta compactação externa pode ser aplicada com a opção de linha do comando "ghe-cluster-suport-bundle -c".

Incluímos texto adicional ao console de administração para lembrar os usuários da coleta de dados dos aplicativos móveis para fins de melhoria de experiência.

O registro de conexão de dados GitHub Connect agora inclui uma lista de funcionalidades habilitadas de GitHub Connect. [Atualizado em 2021-12-09]

Foi identificada uma vulnerabilidade de transversalidade de caminho em compilações GitHub Pages em GitHub Enterprise Server que poderia permitir que um invasor lesse os arquivos do sistema. Para explorar esta vulnerabilidade, um invasor precisava de permissão para criar e compilar um site GitHub Pages na instância GitHub Enterprise Server. Esta vulnerabilidade afetou todas as versões de GitHub Enterprise Server anteriores �  3.3 e foi corrigida nas versões 3.0.19, 3.1.11 e 3.2.3. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs GitHub e foi designada CVE-2021-22870.

Os pacotes foram atualizados para as últimas versões de segurança.

Algumas operações Git falharam depois de atualizar um cluster 3.x de GitHub Enterprise Server devido �  configuração do HAProxy.

É possível que as contagens de trabalhadores do Unicorn possam ter sido definidas de modo incorreto no modo de agrupamento.

É possível que as contagens dos trabalhadores do Resqued possam ter sido definidas incorretamente no modo cluster.

Se o status do Firewall Descomplicado do Ubuntu (UFW) estivesse inativo, um cliente não poderia vê-lo claramente nos registros.

Falha ao atualizar de GitHub Enterprise Server 2.x para 3.x quando havia caracteres UTF8 em uma configuração do LDAP.

Algumas páginas e trabalhos relacionados ao Git em segundo plano podem não ser executados em modo cluster com certas configurações do cluster.

O link da documentação para estatísticas do servidor estava quebrado.

Quando uma nova marca foi criada, o push carga Webhook não exibiu um objeto "head_commit" correto. Agora, quando uma nova marca é criada, o push da carga de Webhook agora inclui um objeto head_commit que contém os dados do commit para o qual a nova marca aponta. Como resultado, o objeto head_commit sempre terá os dados de commit do payload de commit after.

A página de log de auditoria da empresa não exibiria eventos de auditoria para secret scanning.

Houve um tempo limite de trabalho insuficiente para reparos da réplica.

A página de versões de um repositório retornaria um erro 500 ao visualizar versões.

Os usuários não foram alertados sobre caracteres unicode bidirecionais potencialmente perigosos ao visualizar os arquivos. Para mais informações, consulte "Aviso sobre texto unicode bidirecional" em the GitHub Blog.

O Hookshot Go enviou métricas do tipo de distribuição que o Collectd não conseguiu tratar, o que causou uma balão de erro de análise.

Os repositórios públicos exibidos resultados inesperados de secret scanning com um tipo de Token desconhecido.

Foram adicionadas melhorias de configuração do Kafka. Ao excluir repositórios, os arquivos de pacotes agora são excluídos imediatamente da conta de armazenamento para liberar espaço. "DestroyDeletedPackageVersionsJob" agora exclui arquivos de pacote da conta de armazenamento para pacotes obsoletos junto com os registros de metadados.

Foi possível que as senhas do texto claro acabassem em certos arquivos de registro.

Inúmeras chaves públicas SSH conhecidamente fracas foram adicionadas �  lista de negação e não podem mais ser registradas. Além disso, versões de GitKraken conhecidas por gerar chaves SSH fracas (7.6.x, 7.7.x e 8.0.0) foram bloqueadas de registrar novas chaves públicas.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Restaurar pode gerar uma falha para o servidor corporativo no modo de agrupamento se o orquestrador não tiver uma boa integridade.

Os codespaces foram exibidos nas configurações da organização.

Várias partes do aplicativo não eram utilizáveis para usuários que são proprietários de várias organizações.

Corrigiu um link em https://docs.github.com.

As otimizações de navegação e desempenho de trabalhos para repositórios com muitas refs.

Os pacotes foram atualizados para as versões de segurança mais recentes.

É possível que os hooks de pre-recebimento personalizados tenham falhado devido a limites de tempo de memória virtual ou CPU muito restritivos.

Em uma configuração de agrupamento do GitHub Enterprise Server, as configurações do Grafo de dependência poderiam ter sido aplicadas incorretamente.

A tentativa de limpar todas as configurações existentes com "ghe-cleanup-settings" falhou em reiniciar o serviço do Console de Gerenciamento.

Durante a desmontagem de replicação via "ghe-repl-teardown", o Memcached falhou ao ser reiniciado.

Durante períodos de carga alta, os usuários receberiam códigos de status HTTP 503 quando os serviços de upstream falhassem em verificações de integridade internas.

Os ambientes de hook de pré-recebimento foram proibidos de chamar o comando cat via BusyBox no Alpine.

O failover de um centro de dados do cluster primário para um centro de dados de cluster secundário foi bem-sucedido, mas o failover de retorno para o centro de dados do cluster original não conseguiu promover os índices do Elasticsearch.

O botão "Importar equipes" na página do Teams de uma Organização retornou um HTTP 404.

O uso da API para desabilitar a digitalização de segredo desabilitou a propriedade, mas retornou incorretamente um HTTP 422 e uma mensagem de erro.

Em alguns casos, os administradores do GitHub Enterprise que tentavam ver a página "Dormant users" receberam a resposta "502 Bad Gateway" ou "504 Gateway Timeout".

O impacto no desempenho foi negativo em certas situações de alta carga como resultado do aumento do número de trabalhos "SynchronizePullRequestJob".

Um padrão definido pelo usuário para a Digitalização de Segredo continuaria a ser digitalizado mesmo depois de ser excluído.

Agora os aplicativos GitHub definem o recurso de Digitalização de Segredo em um repositório de forma consistente com a API.

GitHub Advanced Security customers can now specify custom patterns for secret scanning. When a new pattern is specified, secret scanning searches a repository's entire Git history for the pattern, as well as any new commits.

User defined patterns are in beta for GitHub Enterprise Server 3.2. They can be defined at the repository, organization, and enterprise levels. For more information, see "Defining custom patterns for secret scanning."

GitHub Advanced Security customers now have an organization-level view of the application security risks detected by code scanning, Dependabot, and secret scanning. The security overview shows the enablement status of security features on each repository, as well as the number of alerts detected.

In addition, the security overview lists all secret scanning alerts at the organization level. Similar views for Dependabot and code scanning alerts are coming in future releases. For more information, see "About the security overview."

GitHub Advanced Security customers can now see a rich diff of the dependencies changed in a pull request. Dependency review provides an easy-to-understand view of dependency changes and their security impact in the "Files changed" tab of pull requests. It informs you of which dependencies were added, removed, or updated, along with vulnerability information for these dependencies. For more information, see "Reviewing dependency changes in a pull request."

Environments, environment protection rules, and environment secrets are now generally available for GitHub Actions on GitHub Enterprise Server. For more information, see "Environments."

SSH authentication using a FIDO2 security key is now supported when you add a sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate. For more information, see "Generating a new SSH key and adding it to the ssh-agent."

Dark and dark dimmed themes are now available for the web UI. GitHub Enterprise Server will match your system preferences when you haven't set theme preferences in GitHub Enterprise Server. You can also choose which themes are active during the day and night. For more information, see "Managing your theme settings."

Domains that are not able to be verified can now be approved for email notification routing. Enterprise and organization owners will be able to approve domains and immediately augment their email notification restriction policy, allowing notifications to be sent to collaborators, consultants, acquisitions, or other partners. For more information, see "Verifying or approving a domain for your enterprise" and "Restricting email notifications for your enterprise."

Git Credential Manager (GCM) versions 2.0.452 and later now provide security-hardened credential storage and multi-factor authentication support for GitHub Enterprise Server.

GCM with support for GitHub Enterprise Server is included with Git for Windows versions 2.32 and later. GCM is not included with Git for macOS or Linux, but can be installed separately. For more information, see the latest release and installation instructions in the GitCredentialManager/git-credential-manager repository.

A 'User Agent Referrer Policy' setting has been added to the enterprise settings. This allows an admin to set a stricter Referrer-Policy to hide the hostname of a GitHub Enterprise Server installation from external sites. The setting is disabled by default and is tracked by audit log events for staff and enterprise owners when enabled or disabled. For more information, see "Configuring Referrer Policy for your enterprise."

The MySQL health check was changed to use mysqladmin ping instead of TCP checks, which removes some unnecessary noise in the MySQL error log. Also, Orchestrator failover checks were improved to prevent unnecessary MySQL failovers when applying cluster config changes.

The Resque service, which supports background job processing, has been replaced with Aqueduct Lite. This change makes the job system easier to manage and should not affect the user experience. For the new administration and debugging commands for Aqueduct, see "Command-line utilities."

The format of authentication tokens for GitHub Enterprise Server has changed. The change affects the format of personal access tokens and access tokens for OAuth Apps, as well as user-to-server, server-to-server, and refresh tokens for GitHub Apps.

The different token types now have unique identifiable prefixes, which allows for secret scanning to detect the tokens so that you can mitigate the impact of someone accidentally committing a token to a repository. GitHub recommends updating existing tokens as soon as possible. For more information, see "About authentication to GitHub" and "About secret scanning."

Repositories on user profiles and organization profiles now support sorting by star count.

When viewing the commit history of a single file, you can now click to view that file at the selected point in history.

When a submodule is defined with a relative path in your GitHub Enterprise Server instance, the submodule is now clickable in the web UI. Clicking the submodule in the web UI will take you to the linked repository. Previously, only submodules with absolute URLs were clickable. This is supported for relative paths for repositories with the same owner that follow the pattern ../REPOSITORY or relative paths for repositories with a different owner that follow the pattern ../OWNER/REPOSITORY. For more information about working with submodules, see Working with submodules on the GitHub Blog.

The web UI can now be used to synchronize an out-of-date branch of a fork with the fork's upstream branch. If there are no merge conflicts between the branches, the branch is updated either by fast-forwarding or by merging from upstream. If there are conflicts, you will be prompted to create a pull request to resolve the conflicts. For more information, see "Syncing a fork."

The markdown editor used when creating or editing a release in a repository now has a text-editing toolbar. For more information, see "Managing releases in a repository."

Uploading video files is now supported everywhere you write Markdown on GitHub Enterprise Server. Share demos, reproduction steps, and more in your issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "Attaching files."

Markdown files will now automatically generate a table of contents in the header when there are 2 or more headings. The table of contents is interactive and links to the selected section. All 6 Markdown heading levels are supported.

There is a new keyboard shortcut, cmd+e on macOS or ctrl+e on Windows, to insert codeblocks in Markdown files, issues, pull requests, and comments.

Appending ?plain=1 to the URL for any Markdown file will now display the file without rendering and with line numbers. The plain view can be used to link other users to specific lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file. For more information, "Creating a permanent link to a code snippet."

With the latest version of Octicons, the states of issues and pull requests are now more visually distinct so you can scan their status more easily. For more information, see the GitHub Blog.

A new "Require conversation resolution before merging" branch protection rule and "Conversations" menu is now available. Easily discover your pull request comments from the "Files changed" tab, and require that all your pull request conversations are resolved before merging. For more information, see "About pull request reviews" and "About protected branches."

To prevent the merge of unexpected changes after auto-merge is enabled for a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository. Users without write access can still update the pull request with changes from the base branch when auto-merge is enabled. To prevent a malicious user from using a merge conflict to introduce unexpected changes to the pull request, auto-merge for the pull request is disabled if the update causes a merge conflict. For more information about auto-merge, see "Automatically merging a pull request."

People with maintain permissions can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only people with admin permissions could manage this setting. Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs. For more information, see "Managing auto-merge for pull requests in your repository."

The assignees selection for issues and pull requests now supports type ahead searching so you can find users in your organization faster. Additionally, search result rankings have been updated to prefer matches at the start of a person's username or profile name.

When a review is requested from a team of more than 100 people, developers are now shown a confirmation dialog box in order to prevent unnecessary notifications for large teams.

Back-tick code blocks are now supported in issue titles, pull request titles, and in any place issue and pull request titles are referenced in GitHub Enterprise Server.

Events for pull requests and pull request reviews are now included in the audit log for both enterprises and organizations. These events help admins better monitor pull request activity and help ensure security and compliance requirements are being met. Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For more information, see "Reviewing the audit log for your organization."

The default branch name for new repositories is now main. Existing repositories are not impacted by this change. If users, organization owners, or enterprise owners have previously specified a default branch for new repositories, they are also not impacted.

If you want to set a different default branch name, you can do so in the user, organization, or enterprise settings.

Branches, including the default branch, can now be renamed using the the GitHub Enterprise Server web UI. When a branch is renamed, any open pull requests and draft releases targeting the renamed branch will be retargeted automatically, and branch protection rules that explicitly reference the renamed branch will be updated.

Admin permissions are required to rename the default branch, but write permissions are sufficient to rename other branches.

To help make the change as seamless as possible for users:

• A notice is shown to contributors, maintainers, and admins on the repository homepage with instructions for updating their local repository.
• Web requests to the old branch will be redirected.
• A "moved permanently" HTTP response will be returned to REST API calls.
• An informational message is displayed to Git command line users that push to the old branch.

For more information, see "Renaming a branch."

GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret. The GITHUB_TOKEN is an automatically-generated secret that lets you make authenticated calls to the API for GitHub Enterprise Server in your workflow runs. GitHub Actions generates a new token for each job and expires the token when a job completes. The token usually has write permissions to a number of API endpoints, except in the case of pull requests from forks, which are always read. These new settings allow you to follow a principle of least privilege in your workflows. For more information, see "Authentication in a workflow."

GitHub CLI 1.9 and later allows you to work with GitHub Actions in your terminal. For more information, see the GitHub changelog.

The audit log now includes events associated with GitHub Actions workflow runs. This data provides administrators with a greatly expanded data set for security and compliance audits. For more information, see "Reviewing the audit log for your organization."

GitHub Enterprise Server 3.2 contains performance improvements for job concurrency with GitHub Actions. For more information about the new performance targets for a range of CPU and memory configurations, see "Getting started with GitHub Actions for GitHub Enterprise Server."

• The "Maximum Concurrency" values were modified to reflect our most up to date performance testing. [Updated: 2021-12-07]

The GitHub Actions Runner application in GitHub Enterprise Server 3.2 has been updated to v2.279.0.

Any package or package version for GitHub Packages can now be deleted from GitHub Enterprise Server's web UI. You can also undo the deletion of any package or package version within 30 days. For more information, see "Deleting and restoring a package".

The dependency graph can now be enabled using the Management Console, rather than needing to run a command in the administrative shell. For more information, see "Enabling alerts for vulnerable dependencies GitHub Enterprise Server."

Notifications for multiple Dependabot alerts are now grouped together if they're discovered at the same time. This significantly reduces the volume of Dependabot alert notifications that users receive. For more information, see the GitHub changelog.

Dependency graph and Dependabot alerts now support Go modules. GitHub Enterprise Server analyzes a repository's go.mod files to understand the repository’s dependencies. Along with security advisories, the dependency graph provides the information needed to alert developers to vulnerable dependencies. For more information about enabling the dependency graph on private repositories, see "Securing your repository."

The default notification settings for security alerts have changed. Previously, if you had permission to view security alerts in a repository, you would receive notifications for that repository as long as your settings allowed for security alert notifications. Now, you must opt in to security alert notifications by watching the repository. You will be notified if you select All Activity or configure Custom to include Security alerts. All existing repositories will be automatically migrated to these new settings and you will continue to receive notifications; however, any new repositories will require opting-in by watching the repository. For more information see "Configuring notifications for Dependabot alerts" and "Managing alerts from secret scanning."

Code scanning with CodeQL now generates diagnostic information for all supported languages. This helps check the state of the created database to understand the status and quality of performed analysis. The diagnostic information is available starting in version 2.5.6 of the CodeQL CLI. You can see the detailed diagnostic information in the GitHub Actions logs for CodeQL. For more information, see "Viewing code scanning logs."

Code scanning with CodeQL CLI now supports analyzing several languages during a single build. This makes it easier to run code analysis to use CI/CD systems other than GitHub Actions. The new mode of the codeql database create command is available starting version 2.5.6 of the CodeQL CLI. For more information about setting this up, see "Installing CodeQL CLI in your CI system."

Code scanning alerts from all enabled tools are now shown in one consolidated list, so that you can easily prioritize across all alerts. You can view alerts from a specific tool by using the "Tool" filter, and the "Rule" and "Tag" filters will dynamically update based on your "Tool" selection.

Code scanning with CodeQL now includes beta support for analyzing C++20 code. This is only available when building codebases with GCC on Linux. C++20 modules are not supported yet.

The depth of CodeQL's analysis has been improved by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models for several languages (C++, JavaScript, Python, and Java). As a result, CodeQL can now detect even more potential sources of untrusted user data, review the steps through which that data flows, and identify potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts. For more information, see the GitHub changelog.

Code scanning now shows security-severity levels for CodeQL security alerts. You can configure which security-severity levels will cause a check failure for a pull request. The severity level of security alerts can be critical, high, medium, or low. By default, any code scanning alerts with a security-severity of critical or high will cause a pull request check failure.

Additionally, you can now also configure which severity levels will cause a pull request check to fail for non-security alerts. You can configure this behavior at the repository level, and define whether alerts with the severity error, warning, or note will cause a pull request check to fail. By default, non-security code scanning alerts with a severity of error will cause a pull request check failure.

For more information see "Defining which alert severity levels cause pull request check failure."

Improvements to the branch filter for code scanning alerts make it clearer which code scanning alerts are being displayed on the alerts page. By default, code scanning alerts are filtered to show alerts for the default branch of the repository only. You can use the branch filter to display the alerts on any of the non-default branches. Any branch filter that has been applied is shown in the search bar.

The search syntax has also been simplified to branch:<branch name>. This syntax can be used multiple times in the search bar to filter on multiple branches. The previous syntax, ref:refs/heads/<branch name>, is still supported, so any saved URLs will continue to work.

Free text search is now available for code scanning alerts. You can search code scanning results to quickly find specific alerts without having to know exact search terms. The search is applied across the alert's name, description, and help text. The syntax is:

• A single word returns all matches.
• Multiple search words returns matches to either word.
• Words in double quotes returns exact matches.
• The keyword 'AND' returns matches to multiple words.

Secret scanning added patterns for 23 new service providers. For the updated list of supported secrets, see "About secret scanning."

Pagination support has been added to the Repositories REST API's "compare two commits" endpoint, which returns a list of commits reachable from one commit or branch, but unreachable from another. The API can also now return the results for comparisons over 250 commits. For more information, see the "Commits" REST API documentation and "Traversing with pagination."

The REST API can now be used to programmatically resend or check the status of webhooks. For more information, see "Repositories," "Organizations," and "Apps" in the REST API documentation.

Improvements have been made to the code scanning and GitHub Advanced Security APIs:

• The code scanning API now returns the CodeQL query version used for an analysis. This can be used to reproduce results or confirm that an analysis used the latest query. For more information, see "Code scanning" in the REST API documentation.
• Admin users can now use the REST API to enable or disable GitHub Advanced Security for repositories, using the security_and_analysis object on repos/{org}/{repo}. In addition, admin users can check whether Advanced Security is currently enabled for a repository by using a GET /repos/{owner}/{repo} request. These changes help you manage Advanced Security repository access at scale. For more information, see "Repositories" in the REST API documentation.

On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

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

In some cases, GitHub Advanced Security customers who upgrade to GitHub Enterprise Server 3.5 or later may notice that alerts from secret scanning are missing in the web UI and REST API. To ensure the alerts remain visible, do not skip 3.4 when you upgrade from an earlier release to 3.5 or later. A fix is available in the 3.5.5 and 3.6.1 patch releases.

To plan an upgrade through 3.4, see the Upgrade assistant. [Updated: 2022-09-01]

GitHub Enterprise Server 2.21 was discontinued on June 6, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

GitHub Enterprise Server 2.22 will be discontinued on September 23, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

Beginning in GitHub Enterprise Server 3.1, we will begin discontinuing support for Xen Hypervisor. The complete deprecation is scheduled for GitHub Enterprise Server 3.3, following the standard one year deprecation window. Please contact GitHub Support with questions or concerns.

GitHub Enterprise Server 3.2 removes unused GitHub Service database records. More information is available in the deprecation announcement post.

To prevent accidental logging or exposure of access_tokens, we discourage the use of OAuth Application API endpoints and the use of API auth via query params. Visit the following posts to see the proposed replacements:

• Replacement OAuth Application API endpoints
• Replacement auth via headers instead of query param

These endpoints and auth route are planned to be removed from GitHub Enterprise Server in GitHub Enterprise Server 3.4.

Two legacy GitHub Apps-related webhook events have been removed: integration_installation and integration_installation_repositories. You should instead be listening to the installation and installation_repositories events.

The following REST API endpoint has been removed: POST /installations/{installation_id}/access_tokens. You should instead be using the namespaced equivalent POST /app/installations/{installation_id}/access_tokens.

GitHub Connect will no longer work after June 3rd for instances running GitHub Enterprise Server 3.1 or older, due to the format of GitHub authentication tokens changing. To continue using GitHub Connect, upgrade to GitHub Enterprise Server 3.2 or later. For more information, see the GitHub Blog. [Updated: 2022-06-14]