Enterprise Server 3.2 release notes

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

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.

MÉDIO: Identificou-se um problema de segurança no resolvedor do nginx, em que um invasor que poderia forjar pacotes UDP do servidor DNS pode fazer com que a memória de 1 byte seja sobrescrita, resultando em falhas no processo dos trabalhadores ou outros impactos potencialmente prejudiciais. A vulnerabilidade foi atribuída CVE-2021-23017.

Atualizadou as ações actions/checkout@v2 e actions/checkout@v3 para endereçar novas vulnerabilidades anunciadas na [postagem do blogue de aplicação de segurança do Git](https://github.blog/2022-04-12-git-security-vulnerability-announced ced/).

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

Em algumas topologias de agrupamento, o comando ghe-cluster-status ignorou diretórios vazios em /tmp.

O SNMP registrou incorretamente um número alto de mensagens de erro Cannot statfs para o syslog.

Para instâncias configuradas com a autenticação SAML e o recurso interno habilitado, usuários integrados ficariam presos em um loop de "login" ao tentar efetuar o login a partir da página gerada após o logout.

Vídeos enviados para comentários de problemas não seriam interpretados corretamente.

Ao usar declarações criptografadas do SAML, algumas afirmações não estavam marcando corretamente chaves SSH como verificada.

Ao usar ghe-migrator, uma migração falharia na importação de anexos do arquivo de vídeo em problemas e pull requests.

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

Nas configurações de alta disponibilidade, explique que a página de visão geral de replicação no Console de Gerenciamento exibe somente a configuração de replicação atual, não o status de replicação atual.

Ao habilitar GitHub Package Registry, explique que o uso de um token de Assinatura de Acesso Compartilhado (SAS) como string de conexão não é compatível atualmente.

Pacotes de suporte agora incluem a contagem de linhas armazenadas no MySQL.

O gráfico de dependência agora pode ser habilitado sem dados de vulnerabilidade, permitindo que você veja quais dependências estão em uso e em que versões. Habilitar o Gráfico de Dependência sem habilitar GitHub Connect não fornecerá informações de vulnerabilidade.

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

Atualizar os nós em um par de alta disponibilidade com um pacote de atualização pode fazer com que o Elasticsearch entre em um estado inconsistente em alguns casos.

Em algumas topologias de cluster, os utilitários de linha de comando 'ghe-spokesctl' e 'ghe-btop' falharam em executar.

Os índices de pesquisa do Elasticsearch podem ser duplicados durante uma atualização do pacote, devido a um serviço elasticsearch-upgrade em execução várias vezes em paralelo.

Ao converter a conta de um usuário em uma organização, se a conta de usuário era proprietáris da conta corporativa de GitHub Enterprise Server, a organização convertida apareceria incorretamente na lista de proprietários da empresa.

Criar um token OAuth de representação usando a API REST da administração corporativa funcionou incorretamente quando uma integração que corresponde ao ID do aplicativo OAuth já existia.

Os erros de configuração que interrompem a execução de uma configuração aplicada agora são retornados para o terminal, além do log de configuração.

Ao tentar armazenar em cache um valor maior que o máximo permitido no Memcached, ocorreu um erro, porém a chave não foi relatada.

O fluxo de trabalho inicial de CodeQL não mais gera erros, mesmo se as permissões padrão de token para GitHub Actions não forem usadas.

Se as funcionalidades de Segurança Avançada GitHub estiverem habilitadas na sua instância, o desempenho de trabalhos em segundo plano melhorou ao processar lotes para contribuições no repositório.

MÉDIO: Uma vulnerabilidade de travessia de caminho foi identificada em GitHub Enterprise Server Console de Gerenciamento que permitiu ignorar as proteções do CSRF. Esta vulnerabilidade afetou todas as versões de GitHub Enterprise Server antes anteriores à 3.5 e foi corrigida nas versões 3.1.19, 3.2.11, 3.3.6, 3.4.1. Essa vulnerabilidade foi reportada através do programa de compensação de erros de GitHub e recebeu o CVE-2022-23732.

MÉDIO: Foi identificada uma vulnerabilidade de sobrefluxo no branch 1.x e no branch 2.x do yajil, que leva à subsequente corrupção de memória heap ao lidar com entradas grandes (~2 GB). Esta vulnerabilidade foi relatada internamente e recebeu o CVE-2022-24795.

Os pacotes de suporte podem incluir arquivos sensíveis se GitHub Actions foi habilitado.

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

os processos do Minio teriam alto uso de CPU se uma opção antiga de configuração estivesse presente após a atualização de GitHub Enterprise Server.

As opções para habilitar TLS 1.0 e TLS 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, a configuração da replicação do MSSQL pode exigir etapas manuais adicionais depois de habilitar GitHub Actions pela primeira vez.

Um subconjunto de arquivos de configuração interna são atualizados de forma mais confiável após um hotpatch.

O script ghe-run-migrations às vezes falha ao gerar nomes de certificados temporários corretamente.

Em um ambiente de cluster, as operações de FLS do Git podem falhar com chamadas de API interna com falhas que cruzaram vários nós web.

Os hooks pre-receive que usavam gpg --import venceram devido a privilégios insuficientes de syscall.

Em algumas topologias de cluster, as informações de entrega de webhook não estavam disponíveis.

Em configurações HA, derrubar uma réplica geraria uma falha se GitHub Actions tivesse sido habilitado anteriormente.

As verificações de integridade do Elasticsearch não permitiriam um estado de cçister amarelo ao realizar migrações.

As organizações criadas como resultado de um usuário transformar sua conta de usuário em uma organização não foram adicionadas à conta corporativa global.

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

O gráfico de implantação de GitHub Actions exibirá um erro ao interpretar um trabalho pendente.

Os links para páginas inacessíveis foram removidos.

Sair de uma comparação de dois commits na interface de usuário web faria com que o diff persistisse em outras páginas.

Adicionar uma equipe como revisora a um pull request às vezes poderia mostrar o número incorreto de integrantes dessa equipe.

O terminal API Remover a associação da equipe para um usuário responderia com um erro quando tentava remover um integrante gerenciado externamente por um grupo SCIM.

Um grande número de usuários inativos pode causar falha na configuração de GitHub Connect.

A página "Cadastros e recursos betaa" na interface de administração do site estava disponível de forma incorreta.

O link "Modo de administrador do site" no rodapé não mudou de status quando 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 Memcached foram aumentados para melhor acomodar as topologias de grandes clusters.

A API do Gráfico de Dependência correu anteriormente com uma porta definida estaticamente.

As contagens de fragmentos padrão para fragmentos do Elasticsearch relacionados ao clusters foram atualizadas.

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

O desempenho foi melhorado para solicitações da web feitas por proprietários das empresas.

ALTO: Uma vulnerabilidade de sobrefluxo de inteiros foi identificada no analisador do markdown do GitHub que poderia potencialmente levar a vazamentos de informações e a RCE. Essa vulnerabilidade foi relatada através do programa de compensação de erros do GitHub por Felix Wilhelm do Projeto Zero do Google, e foi atribuída ao CVE-2022-24724.

As atualizações às vezes poderiam falhar se o relógio da réplica de alta disponibilidade estivesse fora de sincronia com o primário.

Os aplicativos OAuth criados após 1 de setembro, 2020 não conseguiram de usar o ponto de extremidade da 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 Azure Blob Storage 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 para segredos.

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

O Pages ficaria indisponível após uma rotação do segredo do MySQL até nginx ser reiniciado manualmente.

As migrações podem falhar quando GitHub Actions foi habilitado.

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

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

O número da versão não poderia ser atualizado corretamente após a instalação de um hotpatch 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 no primário, o ghe-repl-teardown em uma réplica não remove a réplica do grupo de disponibilidade do MSSQL.

Ao usar a autenticação CAS e a opção "Reativar usuários suspensos" foi habilitada, os usuários suspensos não foram reativados automaticamente.

A capacidade de limitar notificações com base em e-mail para usuários com e-mails 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, o Log4j foi atualizado para a versão 2.17.1. Observação: as mitigações anteriores lançadas em 3.3.1, 3.2.6, 3.1.14 e 3.0.22 são suficientes para resolver o impacto do CVE-2021-44228, do CVE-2021-45046, do CVE-2021-45105 e do 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 falhariam 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 quando configurar o MinIO como armazenamento blob 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.

Gráficos 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: A vulnerabilidade da execução de um código remoto na biblioteca Log4j, identificada como CVE-2021-44228 afetou todas as versões de GitHub Enterprise Server anteriores a 3.3.1. A biblioteca Log4j é usada comom um serviço de código aberto em execução na instância de 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 obter mais informações, consulte essa postagem no blogue do GitHub.

Atualização de 17 de dezembro de 2021: As correções em vigor para esta versão também mitigam o [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename. gi?name=CVE-2021-45046), que foi publicado após esta versão. Nenhuma atualização adicional para GitHub Enterprise Server é necessária para mitigar CVE-2021-44228 e CVE-2021-45046.

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

Uma vulnerabilidade incorreta da UI foi identificada no GitHub Enterprise Server que permitiu que mais permissões fossem concedidas durante o fluxo da web de autorização de usuário do aplicativo GitHub do que foram exibidas para o usuário durante a aprovação. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server antes da versão 3.3 e foi corrigida nas versões 3.2.5, 3.1.13, 3.0.21. Esta vulnerabilidade foi informada por meio do programa de Compensação de Erros do GitHub e recebeu CVE-2021-41598.

Uma vulnerabilidade de execução de código remoto foi identificada no GitHub Enterprise Server que pode ser explorada ao criar um site do GitHub Pages. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server antes de 3.3 e foi corrigida nas versões 3.0.21, 3.1.13 e 3.2.5. Esta vulnerabilidade foi informada no programa de Compensação de Erro do GitHub e recebeu um [CVE-2021-41599](https://www. ve.org/CVERecord?id=CVE-2021-41599). Atualizado em 17 de fevereiro 2022.

Em alguns casos quando o Ações não foi habilitado, o ghe-support-bundle informou uma mensagem inesperada Unable to find MS SQL container.

À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 manteriam abertos após a rotação de um registro.

As migrações podem ficar presas devido à manipulação incorreta de valores blob_path que não sã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 org não continuariam com os parâmetros de consulta.

Durante um hotpatch, foi possível duplicar hashes se uma transição correu 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 últimas versões de segurança.

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 hooks de pre-receive falhariam em razão de PATH indefinido.

A execução de ghe-repl-setup retornaria um erro: cannot create directory /data/user/elasticsearch: File exists se a instância tiver sido configurada anteriormente como uma réplica.

Executar ghe-support-bundle retornou um erro: integer expression expected.

Após configurar uma réplica de alta disponibilidade, o 'ghe-repl-status' incluiu um erro na saída: unexpected unclosed action in command.

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

Alguns serviços críticos podem não estar disponíveis em nós de backend 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 sobre o objeto Team no esquema GraphQL produziu resultados incorretos em algumas circunstâncias.

Em uma configuração de alta disponibilidade, a manutenção de repositório sempre apareceu como falha nas ferramentas do staffy, mesmo quando foi bem-sucedida.

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

A camada externa adicional de compressão gzip ao criar um pacote de suporte de cluster com ghe-cluster-suport-bundle agora está desativada por padrão. Essa compressão externa pode ser aplicada opcionalmente com a opção de linha de comando ghe-cluster-suport-bundle -c.

Nós adicionamos 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 de GitHub Connect habilitadas. [Atualizado em 2021-12-09]

Foi identificada uma vulnerabilidade de travessia de caminhos em GitHub Pages com base em GitHub Enterprise Server, que poderia permitir a um invasor ler arquivos de sistema. Para explorar essa vulnerabilidade, um invasor precisava de permissão para criar e construir um site de GitHub Pages na instância de GitHub Enterprise Server. Essa vulnerabilidade afetou todas as versões de GitHub Enterprise Server anteriores à versão 3.3, e foi corrigida nas versões 3.0.19, 3.1.11 e 3.2.3. Esta vulnerabilidade foi informada por meio do programa de compensação de erros do GitHub e recebeu 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 forma incorreta 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 oa 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 tag foi criada, a push carga do webhook não mostrou um objeto head_commit correto. Agora, quando uma nova tag é criada, a carga do webhook de push sempre inclui um objeto head_commit que contém os dados do commit para o qual a nova tag aponta. Como resultado, o objeto head_commit sempre conterá os dados de commit do commit do commit after da carga.

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

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 avisados sobre caracteres bidirecionais potencialmente perigosos do unicode ao visualizar arquivos. Para obter mais informações, consulte "Aviso sobre texto bidirecional do Unicode" em 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 varredura secreta 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.

Várias chaves públicas SSH fracas conhecidas foram adicionadas à lista de recusas e já não podem ser registradas. Além disso, as versões do GitKraken conhecidas por gerar chaves SSH fracas (7.6.x, 7.7.x e 8.0.0) foram impedidas de registrar novas chaves públicas.

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

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

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

Várias partes do aplicativo eram inutilizá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 últimas versões de segurança.

É possível que os hooks pre-receive 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 gráfico de dependência poderiam ter sido aplicadas incorretamente.

A tentativa de limpar todas as configurações existentes com ghe-cleanup-settings falhou ao 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 falharam em verificações de saúde internas.

Os ambientes de hook pre-receive foram proibidos de chamar o comando cat via BusyBox no Alpine.

A recuperação da falha de um centro de dados do cluster primário para um centro de dados de cluster secundário foi bem-sucedida, mas a recuperação da falha 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 para 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 recebeu a resposta 502 Bad Gateway ou 504 Gateway Timeout.

O desempenho foi impactado negativamente 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 sendo digitalizado mesmo depois de ter sido excluído.

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

Os clientes de Segurança Avançada GitHub agora podem especificar padrões personalizados para a digitalização de segredo. Quando um novo padrão for especificado, a digitalização de segredo irá pesquisar todo o histórico do Git de um repositório para o padrão, bem como quaisquer novos commits.

Os padrões definidos pelo usuário estão em beta para GitHub Enterprise Server 3.2. Eles podem ser definidos nos níveis do repositório, organização e empresa. Para obter mais informações, consulte "Definir padrões personalizados para digitalização de segredoa."

Os clientes de Segurança Avançada GitHub agora têm uma visão a nível da organização dos riscos de segurança do aplicativo detectados por Varredura de código, Dependabot e varredura secreta. A visão geral de segurança mostra o status de habilitação das funcionalidades de segurança em cada repositório, bem como o número de alertas detectados.

Além disso, a visão geral de segurança lista todos os alertas de varredura secreta no nível da organização. As visualizações similares para os alertas de Dependabot e Varredura de código serão implementadas em versões futuras. Para obter mais informações, consulte "Sobre a visão geral de segurança.

Os clientes de Segurança Avançada GitHub agora podem ver um diff avançado das dependências alteradas em um pull request. A revisão de dependências fornece uma visão de fácil compreensão de alterações das dependências e o seu impacto de segurança na aba "Arquivos alterados" dos pull requests. Ele informa quais dependências foram adicionadas, removidas ou atualizadas, junto com informações sobre vulnerabilidade para essas dependências. Para obter mais informações, consulte "Revisar as alterações de dependências em um pull request."

As ambientes, regras de proteção do ambiente e segredos de ambiente agora estão geralmente disponíveis para GitHub Actions em GitHub Enterprise Server. Para obter mais informações, consulte "Environments."

A autenticação SSH usando uma chave de segurança FIDO2 agora é compatível quando você adiciona uma Chave SSH sk-ecdsa-sha2-nistp256@openssh.com ou sk-ssh-ed25519@openssh.com à sua conta. As chaves de segurança SSH armazenam material da chave do segredo em um dispositivo de hardware separado que exige verificação, como um toque, para operar. Para obter mais informações, consulte "Gerar uma nova chave SSH e adicioná-la ao ssh-agent."

Os temas escuros e sombreados estão disponíveis agora para a interface do usuário da web. GitHub Enterprise Server irá corresponder as suas preferências de sistema quando você não definiu preferências de tema em GitHub Enterprise Server. Você também pode escolher quais temas estão ativos durante o dia e a noite. Para obter mais informações, consulte "Gerenciando as configurações do tema.

Os domínios que não podem ser verificados agora podem ser aprovados para encaminhamento de notificação de e-mail. Os proprietários de empresas e organizações poderão aprovar domínios e ampliar imediatamente sua política de restrição de notificação por e-mail, permitir que sejam enviadas notificações para colaboradores, consultores, aquisições ou outros parceiros. Para obter mais informações, consulte "Verificando ou aprovando um domínio para sua empresa" e "Restringindo notificações de e-mail para sua empresa."

As versões 2.0.452 e posteriores do Gerenciador de Credencial Git (GCM) agora fornecem armazenamento de credenciais consolidado com segurança e suporte de autenticação multifatorial para GitHub Enterprise Server.

O GCM com suporte para GitHub Enterprise Server está incluído em Git para Windows versões 2.32 ou posteriores. O GCM não está incluído no Git para macOS ou Linux, mas pode ser instalado separadamente. Para obter mais informações, consulte a [versão mais recente](https://github. om/GitCredentialManager/git-credential-manager/releases/) e instruções de instalação no repositório GitCredentialManager/git-credential-manager.

Uma definição da 'Política de Indicação de Agente de Usuário' foi adicionada às configurações da empresa. Isso permite que um administrador defina uma Política de Indicação- mais rigorosa para ocultar o nome do host de uma instalação de GitHub Enterprise Server a partir de sites externos. A configuração está desabilitada por padrão e é rastreada pelos eventos de log de auditoria para funcionários e proprietários da empresa quando habilitado ou desabilitado. Para obter mais informações, consulte "Configurar a Política de Indicação para a sua empresa."

A verificação de integridade do MySQL foi alterada para usar mysqladmin ping em vez de verificações TCP, o que remove algum ruído desnecessário no registro de erros do MySQL. Além disso, as verificações de falha do Orchestrator foram aprimoradas para evitar falhas desnecessárias do MySQL ao aplicar alterações de configuração de cluster.

O serviço do Resque, que é compatível com o processamento de trabalhos em segundo plano, foi substituído pelo Aqueduct Lite. Esta alteração facilita o gerenciamento do sistema de trabalho e não deve afetar a experiência do usuário. Para os novos comandos de administração e depuração para Aqueduct, consulte "Utilitários de linha de comando."

O formato de autenticação de tokens para GitHub Enterprise Server foi alterado. A alteração afeta o formato dos tokens de acesso pessoal e tokens de acesso para Aplicativos OAuth, bem como os tokens de usuário para servidor, servidor para servidor e tokens de atualização para Aplicativos do GitHub.

Os diferentes tipos de token agora têm prefixos identificáveis exclusivos, o que permite que a digitalização de segredos detecte os tokens para que você possa mitigar o impacto de alguém acidentalmente fazer o commit de um token em um repositório. GitHub recomenda atualizar os tokens existentes o mais rápido possível. Para obter mais informações, consulte "Sobre a autenticação para GitHub" e "Sobre varredura secreta."

Repositórios em perfis de usuários e perfis da organização agora são compatíveis com a classificação por contagem de estrelas.

Ao visualizar o histórico de commit de um único arquivo, agora você pode clicar em para ver esse arquivo no ponto selecionado no histórico.

Quando um submódulo é definido com um caminho relativo em your GitHub Enterprise Server instance, será poss[ivel clicar no submódulo na interface do usuário web. Clicando no submódulo na interface do usuário web irá levá-lo para o repositório vinculado. Anteriormente, era possível clicar apenas em submódulos com URLs absolutos. Isto é vompatível com caminhos relativos para repositórios com o mesmo proprietário que segue o padrão .,/REPOSITORY ou caminhos relativos para repositórios com um proprietário diferente que segue o padrão .,/OWNER/REPOSITORY. Para obter mais informações sobre como trabalhar com submódulos, consulte Trabalhando com submódulos em GitHub Blog.

Agora a interface do usuário web pode ser usada para sincronizar um branch desatualizado de uma bifurvação com o branch a upstream da nifurcação. Se não houver conflitos de merge entre os branches, o branch será atualizado tanto por encaminhamento rápido quanto pelo merge upstream. Se houver conflitos, será solicitado que você crie um pull request para resolver os conflitos. Para obter mais informações, consulte "Sincronizando um fork."

O editor de markdown usado ao criar ou editar uma versão em um repositório agora tem uma barra de ferramentas de edição de texto. Para obter mais informações, consulte "Gerenciar versões em um repositório."

O upload de arquivos de vídeo agora é compatível em todos os todos os lugares no Markdown em GitHub Enterprise Server. Compartilhe demonstrativos, etapas de reprodução e muito mais em comentários fos seus problemas e pull request, bem como em arquivos de Markdown dentro de repositórios, como READMEs. Para obter mais informações, consulte "Anexando arquivos".

Os arquivos de Markdown agora irão gerar automaticamente uma tabela de conteúdo no cabeçalho quando houver dois ou mais cabeçalhos. A tabela de conteúdo é interativa e links para a seção selecionada. Todos os 6 níveis de cabeçalho do Markdown são compatíveis.

Há um novo atalho de teclado, cmd+e no macOS ou ctrl+e no Windows, para inserir blocos de código em arquivos de Markdown, problemas, pull requests e comentários.

Adicionar ?plain=1 ao URL para qualquer arquivo de Markdown agora irá exibir o arquivo sem interpretação e com números de linha. A visualização simples pode ser usada para vincular outros usuários a linhas específicas. Por exemplo, ao adicionar ?plain=1#L52 você destacará a linha 52 de um arquivo de Markdown em texto simples. Para obter mais informações, "Criar um link permanente para um trecho de código".

Com a versão mais recente do Oticons, os estados dos problemas e pull requests agora são mais visualmente distintos para que você possa digitalizar o status de forma mais fácil. Para obter mais informações, consulte GitHub Blog.

Uma nova regra de proteção do branch "Exigir resolução de conversação antes do merge " e o menu de "Conversas" agora estão disponíveis. Descubra facilmente os comentários de pull request na aba "Arquivos alterados" e exija que todas as suas conversas de pull request sejam resolvidas antes do merge. Para obter mais informações, consulte "Sobre revisões do pull request" e "Sobre branches protegidos."

Para evitar o merge de alterações inesperadas após merge automático ser habilitado para um pull request, o merge automático agora é desabilitado automaticamente quando novas alterações são enviadas por push por um usuário sem acesso de gravação ao repositório. Os usuários sem acesso de gravação ainda podem atualizar o pull request com alterações do branch base quando o merge automático está habilitado. Para evitar que um usuário malicioso use um conflito de merge para introduzir alterações inesperadas no pull request, o merge automático do pull request está desabilitado se a atualização causar um conflito de merge. Para obter mais informações sobre o merge automático, consulte "[Fazer merge automaticamente de um pull request](/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automaticamente, merging-a-pull-request)."

As pessoas com permissões de manutenção agora podem gerenciar a configuração para "Permitir merge automático". Esta configuração, que está desabilitada por padrão, controla se o merge automático está disponível em pull requests no repositório. Anteriormente, apenas pessoas com permissões de administrador poderiam gerenciar essa configuração. Além disso, essa configuração agora pode usar as API REST "Criar um repositório" e "Atualizar um repositório". Para obter mais informações, consulte "Gerenciar merge automático para pull requests no seu repositório."

A seleção de responsáveis para problemas e pull requests agora é compatível com a digitação antecipada para que você possa encontrar usuários na sua organização mais rapidamente. Além disso, as classificações do resultado da pesquisa foram atualizadas para preferir as partidas no início do nome de usuário de uma pessoa ou nome do perfil.

Quando uma revisão é solicitada a uma equipe de mais de 100 pessoas, os desenvolvedores agora são mostrados uma caixa de diálogo de confirmação, a fim de evitar notificações desnecessárias para grandes equipes.

Os 'blocos de código' com aspas inversas agora são compatíveis nos títulos de problemas, títulos de pull request e em qualquer lugar em que se fazem referência aos problemas e títulos de pull request GitHub Enterprise Server.

Os eventos para pull requests e revisões de pull request agora são incluídos no log de auditoria de enterprises e organizations. Esses eventos ajudam os administradores a monitorar melhor a atividade de pull request e ajudam a garantir que os requisitos de segurança e conformidade estejam sendo cumpridos. Os eventos podem ser vistos na interface do usuário da web, exportados como CSV ou JSON, ou acessados via API REST. Você também pode pesquisar no log de auditoria por eventos específicos de pull request. Para obter mais informações, consulte "Revisando o log de auditoria da sua organização."

O nome do branch padrão para novos repositórios agora é main. Os repositórios existentes não são impactados por esta alterção. Se os usuários, proprietários da organização ou proprietários corporativos especificaram anteriormente um branch padrão para novos repositórios, eles também não serão impactados.

Se você quiser definir um nome de branch padrão diferente, você pode fazê-lo em user, organization, ou enterprise.

Os branches, incluindo o branch padrão, agora pode ser renomeado usando a interface de usuário do site GitHub Enterprise Server. Quando um branch é renomeado, todos os pull requests em aberto e rascunhos de versões direcionados ao branch renomeado serão automaticamente direcionados e as regras de proteção de branch que fazem referência explicitamente ao branch renomeado serão atualizadas.

As permissões de administrador são necessárias para renomear o branch padrão, mas as permissões de gravação são suficientes para renomear outros branches.

Para ajudar a tornar a alteração o mais perfeita possível para os usuários:

• Um aviso é apresentado para os colaboradores, mantenedores e administradores na página inicial do repositório com instruções para atualizar seus repositórios locais.
• As solicitações da Web para o branch antigo serão redirecionadas.
• A resposta HTTP "movida permanentemente" será retornada para chamadas da API REST.
• Uma mensagem informativa é exibida para usuários de linha de comando do Git que fazem push para o branch antigo.

Para obter mais informações, consulte "Renomeando um branch".

GitHub Actions agora permite que você controle as permissões concedidas ao segredo GITHUB_TOKEN. O GITHUB_TOKEN é um segredo gerado automaticamente que permite que você faça chamadas autenticadas para a API para GitHub Enterprise Server no seu fluxo de trabalho. GitHub Actions gera um novo token para cada job e expira o token quando um trabalho é concluído. O token geralmente tem permissões write para um número de pontos de extremidade da API, exceto no caso de pull requests das bifurcações, que são sempre read. Estas novas configurações permitem que você siga um princípio de "menor privilégio" nos fluxos de trabalho. Para obter mais informações, consulte "Autenticação no fluxo de trabalho."

GitHub CLI 1.9 e versões posteriores permitem que você trabalhe com GitHub Actions no seu terminal. Para obter mais informações, consulte o registro de altrações de GitHub.

O log de auditoria agora inclui eventos associados a execuções do fluxo de trabalho de GitHub Actions. Esses dados fornecem aos administradores um conjunto de dados bastante expandido para auditorias de segurança e conformidade. Para obter mais informações, consulte "Revisando o log de auditoria da sua organização."

GitHub Enterprise Server 3.2 contém melhorias de desempenho para a simultaneidade de trabalho com GitHub Actions. Para mais informações sobre os novos objetivos de desempenho em uma variedade de configurações de CPU e memória, consulte "Primeiros passos com GitHub Actions para GitHub Enterprise Server."

• Os valores de "concorrência máxima" foram modificados para refletir os nossos testes de desempenho mais atualizados. [Atualizado: 2021-12-07]

O aplicativo Executor de GitHub Actions em GitHub Enterprise Server 3.2 foi atualizado para v2.279.0.

Qualquer pacote ou versão do pacote para GitHub Package Registry agora pode ser excluída da interface de usuário web de GitHub Enterprise Server. Você também pode desfazer a exclusão de qualquer pacote ou versão do pacote em 30 dias. Para obter mais informações, consulte "Excluir e restaurar um pacote".

O gráfico de dependência agora pode ser habilitado usando o Console de gerenciamento, em vez de precisar executar um comando no shell administrativo. Para obter mais informações, consulte "Habilitando alertas para dependências vulneráveis de GitHub Enterprise Server."

As notificações para vários Alertas do Dependabot agora estão agrupadas se forem descobertas ao mesmo tempo. Isto reduz significativamente o volume de notificações de alerta de Dependabot recebidas pelos usuários. Para obter mais informações, consulte o registro de alterações de GitHub.

O gráfico de dependências e Alertas do Dependabot agora é compatível com os módulos do Go. GitHub Enterprise Server analisa os arquivos go.mod de um repositório para entender as dependências do repositório. Juntamente com consultores de segurança, o gráfico de dependências fornece as informações necessárias para alertar os desenvolvedores para dependências vulneráveis. Para obter mais informações sobre a habilitação do gráfico de dependências em repositórios privados, consulte "Protegendo seu repositório."

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 Alertas do Dependabot" and "Managing alerts from secret scanning."

Varredura de código com CodeQL agora gera informações de diagnóstico para todos os idiomas compatíveis. Isso ajuda a verificar o estado da base de dados criada para entender o status e a qualidade da análise realizada. As informações de diagnóstico estão disponíveis a partir da versão 2.5.6 do [CodeQL CLI](https://codeql. ithub.com/docs/codeql-cli/). Você pode ver as informações detalhadas de diagnóstico nos registros de GitHub Actions para CodeQL. Para obter mais informações, consulte "Exibindo registros de digitalização de código."

Varredura de código com CodeQL CLI agora é compatível com a análise de várias linguagens durante uma única compilação. Isso torna mais fácil executar a análise de código para usar sistemas CI/CD diferentes de GitHub Actions. O novo modo do codeql database create está disponível a partir da [versão 2.5.6](https://github. om/github/codeql-cli-binaries/releases) de CodeQL CLI. Para obter mais informações sobre a configuração desse item, consulte "Instalando CodeQL CLI no seu sistema de CI."

Os alertas de Varredura de código de todas as ferramentas habilitadas agora são exibidos em uma lista consolidada para que você possa facilmente priorizar em todos os alertas. Você pode ver os alertas a partir de uma ferramenta específica, usando o filtro "Ferramenta", e os filtros de "Regra" e "Tag" serão atualizados dinamicamente com base na sua seleção de "ferramenta".

Varredura de código com CodeQL agora inclui suporte de beta para a análise de código C+20. Isto só está disponível quando a criação de bases de códigos com GCC no Linux. Os módulos C++20 ainda não são compatíveis.

A profundidade da análise de CodeQL foi aprimorada, adicionando suporte para mais bibliotecas e estruturas e aumentando a cobertura dos nossos modelos de biblioteca e estruturas existentes para diversas linguagens (C++, JavaScript, Python, and Java). Consequentemente, CodeQL agora pode detectar outras possíveis fontes de dados de usuário não confiáveis, revisar as etapas por meio das quais os dados fluem e identificar possíveis dissipadores perigosos onde os dados podem parar. Isso resulta em uma melhoria geral da qualidade dos alertas de Varredura de código. Para obter mais informações, consulte o registro de alterações de GitHub.

Varredura de código agora mostra níveis de "gravidade" para alertas de segurança do CodeQL. Você pode configurar quais níveis de 'security-severity´ causarão uma falha de verificação para um pull request. O nível de gravidade dos alertas de segurança pode ser crítico, alto, médio ou baixo. Por padrão, todos os alertas de Varredura de código com security-severity crítico ou alto causarão falha de verificação de pull request.

Além disso, agora você também pode configurar quais níveis de gravidade causarão uma falha na verificação de pull request para alertas que não são de segurança. Você pode configurar este comportamento no nível do repositório e definir se os alertas com a gravidadeerro, aviso, ou nota farão com que uma verificação de pull request falhe. Por padrão, os alertas que não são de segurança de Varredura de código com uma gravidade de 'erro' causarão uma falha de verificação de pull request.

Para obter mais informações, consulte "Definir quais níveis de gravidade de alerta causam falha de verificação de pull request.

As melhorias no filtro de branch para alertas de Varredura de código tornam mais claro quais alertas de Varredura de código estão sendo exibidos na página de alertas. Por padrão, os alertas de Varredura de código são filtrados para mostrar alertas somente para o branch padrão do repositório. Você pode usar o filtro de branch para exibir os alertas em qualquer um dos branches não padrão. Qualquer filtro de branch que foi aplicado é mostrado na barra de pesquisa.

A sintaxe de pesquisa também foi simplificada para branch:<branch name>. Esta sintaxe pode ser usada várias vezes na barra de pesquisa para filtrar em vários branches. A sintaxe anterior, ref:refs/heads/<branch name>, ainda é compatível, então todos os URLs salvos continuarão funcionando.

A pesquisa de texto grátis agora está disponível para alertas de digitalização de código. Você pode pesquisar resultados da digitalização de código para encontrar rapidamente alertas específicos sem precisar saber termos de pesquisa exatos. A pesquisa é aplicada por meio do nome, descrição e texto do alerta. A sintaxe é:

• Uma única palavra retorna todas correspondências.
• Múltiplas palavras de pesquisa retornam correspondências para qualquer palavra.
• As palavras em aspas duplas retornam correspondências exatas.
• A palavra-chave 'E' retorna várias palavras.

Varredura secreta adicionou padrões para 23 novos prestadores de serviço. Para a lista atualizada de segredos compatíveis, consulte "Sobre a digitalização de segredo."

O suporte à paginação foi adicionado ao ponto de extremidade "comparar dois commits" da API REST nos repositórios, que retorna uma lista de commits acessíveis a partir de um commit ou branch, mas não podem ser acessados a partir de outro commit ou branch. A API também pode agora devolver os resultados para comparações com mais de 250 commits. Para obter mais informações, consulte a documentação da API REST "Commits" e "Traversing with pagination."

A API REST agora pode ser usada para reenviar ou verificar o status dos webhooks. Para obter mais informações, consulte "Repositories," "Organizations," e "Apps" na documentação da API REST.

Melhorias na verificação de código e nas APIs de Segurança Avançada GitHub:

• A API de digitalização de código agora retorna a versão da consulta do CodeQL usada para uma análise. Isso pode ser usado para reproduzir resultados ou confirmar que uma análise usou a última consulta. Para obter mais informações, consulte "Digitalização de código" na documentação da API REST.
• Os usuários administradores agora podem usar a API REST para habilitar ou desabilitar Segurança Avançada GitHub nos repositórios, usando o objeto security_and_analyis em repos/{org}/{repo}. Além disso, os usuários administradores podem verificar se Segurança Avançada está habilitado para um repositório usando uma solicitação GET /repos/{owner}/{repo}. Essas alterações ajudam você a gerenciar o acesso do repositório Segurança Avançada na escala. Para obter mais informações, consulte "Repositories" na documentação da API REST.

Em uma nova configuração de GitHub Enterprise Server sem qualquer usuário, um invasor pode criar o primeiro usuário administrador.

As regras de firewall personalizadas são removidas durante o processo de atualização.

Arquivos LFS do Git enviados através da interface web são adicionados diretamente ao repositório e de forma incorreta.

Os problemas não podem ser fechados se contiverem um permalink para um blob no mesmo repositório, onde o caminho do arquivo blob's é maior que 255 caracteres.

Quando "Usuários podem pesquisar pelo GitHub.com" está habilitado com o GitHub Connect, os problemas em repositórios privados e internos não estão incluídos nos resultados de pesquisa do GitHub.com.

O registro npm de GitHub Package Registry não retorna mais o valor de tempo em respostas de metadados. Isso foi feito para permitir melhorias substanciais de desempenho. Continuamos a ter todos os dados necessários para devolver um valor de tempo como parte da resposta aos metadados e retomaremos o retorno desse valor no futuro, assim que tivermos resolvido os problemas de desempenho existentes.

Os limites de recursos que são específicos para processamento de hooks pre-receive podem causar falha em alguns hooks pre-receive.

GitHub Enterprise Server 2.21 tornou-se obsoleto em 6 de junho de 2021. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

GitHub Enterprise Server 2.22 irá tornar-se obsoleto em 23 de setembro de 2021. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

A partir de GitHub Enterprise Server 3.1, começaremos a cancelar o suporte para o Hypervisor Xen. A obsolescência completa está agendada para GitHub Enterprise Server 3.3, seguindo o padrão de janela de obsolescência de um ano. Em caso de dúvidas, entre em contato com o suporte do GitHub.

GitHub Enterprise Server 3.2 remove registros de banco de dados do GitHub Service não utilizados. Mais informações estão disponíveis no post de anúncio da obsolescência.

Para evitar o registro acidental ou a exposição de access_tokens, não incentivamos o uso de pontos de extremidade da API do aplicativo OAuth e o uso da autenticação da API usando parâmetros de consulta. Veja os seguintes posts para ver as substituições propostas:

• [Substituição da API do aplicativo OAuth](https://developer.github. om/changes/2020-02-14-deprecating-oauth-app-endpoint/#changes-to-make)
• [Substituição da autenticação usando cabeçalhos em vez de parâmetros de consulta](https://developer.github. om/changes/2020-02-10-deprecating-auth-through-query-param/#changes-to-make)

Estes pontos de extremidade e rota de autenticação estão planejados para serem removidos de GitHub Enterprise Server em GitHub Enterprise Server 3.4.

Dois eventos de webhook relacionados a aplicativos legados foram removidos: integration_installation e integration_installation_repositories. Em vez disso, você deveria estar ouvindo os eventos installation e installation_repositories.

O ponto de extremidade a seguir da API REST foi removido: POST /installations/{installation_id}/access_tokens. Você deverá usar o namespaced equivalente 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]