Enterprise Server 3.1 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 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.

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.

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

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.

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

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.

As filas de trabalho maint_host_low não foram processadas, o que gerou algumas falhas de tarefa de manutenção durante a execução.

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 Enterprise resultou em um erro quando uma integração que corresponde ao ID do Aplicativo OAuth já existia.

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.

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.

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.

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

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

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.

Os limites de conexão Memcached foram aumentados para melhor acomodar as topologias de grandes clusters.

Identificar e excluir logs de webhook de forma mais eficiente que estão fora da janela de retenção de log de webhook.

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.

Exceções NotProcessedError estavam ocorrendo desnecessariamente.

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.

Aplicativos OAuth criados após 1 de setembro, 2020 não puderam de usar o Ponto de extremidade API do Check-Authorization.

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

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

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.

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.

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.

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

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.

À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.

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

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

À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 solicitações do GraphQL não definiram a variável GITHUB_USER_IP em ambientes de hook pre-receive.

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.

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.

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.

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.

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.

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.

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 tiveru ma boa integridade.

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.

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.

Com as ações configuradas, a replicação do MSSQL falharia depois de restaurar de um instantâneo dos utilitários de backup GitHub Enterprise.

Uma mensagem de erro jq incorreta pode ter sido exibida ao executar ghe-config-apply.

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

A senha do banco de dados externo foi conectada em texto simples.

A recuperação de falhas a partir de um centro de dadso de um cluster primário para um centro de dados de cluster secundário foi bem-sucedida, mas recuperar-se das falhas novamente para o centro de dados do cluster original não conseguiu promover índices de Elasticsearch.

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

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.

Para ter melhor efeito, exclua os registros do Webhook que caem da janela de retenção de registro do Webhook.

ALTO: Uma vulnerabilidade transversal de caminho foi identificada em GitHub Enterprise Server, que poderia ser explorada ao criar um site de GitHub Pages. As opções de configuração controladas pelo usuário usadas por GitHub Pages não eram suficientemente restritas e possibilitaram a leitura de arquivos na instância de GitHub Enterprise Server. Para explorar essa vulnerabilidade, um invasor precisaria de permissão para criar e um site de GitHub Pages na instância de GitHub Enterprise Server. Esta vulnerabilidade afetou todas as versões de GitHub Enterprise Server anteriores �  versão 3.1.8 e foi corrigida nas versões 3.1.8, 3.0.16 e 2.22.22. Este é o resultado de uma correção incompleta para o CVE-2021-22867. Esta vulnerabilidade foi relatada por meio do programa de Compensação de Erros do GitHub e recebeu o CVE-2021-22868.

MÉDIO: Uma vulnerabilidade de controle de acesso imprópria em GitHub Enterprise Server permitiu que uma tarefa de fluxo de trabalho fosse executada em um grupo de executores auto-hospedados ao qual não deveria ter acesso. Isto afeta os clientes usando grupos de executores auto-hospedados para controle de acesso. Um repositório com acesso a um grupo de corredores corporativos poderia acessar todos os grupos de executores corporativos dentro da organização por causa das verificações de autenticação inadequadas durante a solicitação. Isso pode fazer com que o código seja executado involuntariamente pelo grupo de executores incorreto. Essa vulnerabilidade afetou GitHub Enterprise Server versões de 3.0.0 até 3.0.15 e 3.1.0 a 3.1.7 e foi corrigido nas versões 3.0.16 e 3.1.8. Atribuiu-se um CVE-2021-22869.

As contagens dos trabalhadores de Resque foram exibidas incorretamente no modo de manutenção.

A memória memorizada memcached poderia ser zero no modo de clustering.

Os arquivos binários não vazios exibiram um tipo de arquivo e tamanho incorreto na aba "Arquivos".

Corrige versões GitHub Pages para que elas levem em conta a configuração NO_PROXY do aparelho. Isto é relevante para os aparelhos configurados apenas com um proxy HTTP. (atualização 2021-09-30)

A configuração do GitHub Connect da instância de origem foi sempre restaurada para novas instâncias mesmo quando --config option for ghe-restore não foi usada. Isto geraria um conflito com a conexão e a sincronização de licença do GitHub Connect se as instâncias de origem e destino estivessem on-line ao mesmo tempo. A correção também exige atualização do backup-utils para a versão 3.2.0 ou superior. [atualizado: 2021-11-18]

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

Tentar derrubar um nó de réplica recém-adicionado especificando o seu UUID com ghe-repl-teardown falharia sem relatar um erro se a replicação não foi iniciada.

As criações do GitHub Pages foram passadas por um proxy externo, caso um tivesse sido configurado.

Hooks pre-receive personalizados que criariam subprocessos carecem de uma variável PATH no seu ambiente, resultando em erros no "arquivo ou diretório não encontrado".

O MySQL poderia falhar durante a atualização se o arquivo 'mysql-auto-failover' foi habilitado.

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

Anexar imagens muito grandes ou GIFs animados a imagens ou pull requests falharia.

As mensagens de Journald relacionadas a atualizações automáticas (Adicionando h/m/s tempo aleatório.) foram registradas no syslog.

Os hooks pre-receive personalizados que criaram pipes nomeados (FIFOs) iriam falhar ou ficar pendentes, gerando um erro de tempo esgotado.

Adicionar filtros ao log de auditoria avançado da página de pesquisa não preencheu a caixa de texto da consulta em tempo real com o prefixo e valor correto da faceta.

Os hooks do Git para a API interna que resultam em solicitações falhadas retornaram a exceção undefined method body for "success":String (NoMethodError) instead of returning an explicit nil.

Quando uma integração foi removida, foi possível que um aplicativo ou integração OAuth não relacionado também fosse removido.

Quando uma mensagem obrigatória que contém um caractere de emoji foi adicionada, tentar visualizar ou mudar a mensagem retornaria um erro de servidor interno de 500.

Adiciona triage e maintain �  lista de permissões retornadas pela API REST.

Os hooks pre-receive personalizados que usavam uma subshell retornariam o erro: No such file or directory.

Quando o GitHub Actions é habilitado sem executar backups regulares o Registro de Transação do MSSQL pode crescer de forma ilimitada e pode consumir todo o espaço disponível no Disco de Dados do aparelho gerando uma possível interrupção.

O registro desnecessário do banco de dados consumiu uma grande quantidade de espaço no disco em instâncias com uso pesado de LFS.

As entradas de log de auditoria das alterações feitas nas configurações da organização "Criação do repositório" estavam imprecisas.

Registro excessivo de exceções de ActionController::UnknownFormat gerou o uso desnecessário de disco.

Os valores de group_dn no LDAP superiores a 255 caracteres resultariam em erros no registro: Dados truncados para a coluna 'group_dn' na linha 1.

Os limites de taxa de abuso são agora denominados limites de taxa secundária, já que o comportamento que eles limitam nem sempre é abusivo.

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

A contagem em páginas de pacotes não estava sendo incrementada quando um pacote foi baixado.

O arquivo ghe-config-apply excederá o tempo-limite, irá solicitar uma instrução ou falhar para um cliente que tinha varredura secreta habilitado e tinha desabilitado ou nunca habilitado GitHub Actions na sua instância.

Arquivos de registro não foram reabertos após rotação em alguns casos, o que gera o uso de espaço em disco em instâncias com tempo de atividade alto.

A atualização pode falhar a partir da versão mais antiga do GitHub Enterprise Server devido a um trabalho que falta em GitHub Actions.

Os hooks pre-receive personalizados podem gerar um erro como error: object directory /data/user/repositories/0/nw/12/34/56/7890/network.git/objects does not exist; check .git/objects/info/alternates.

O Proxy de HTTP não autenticado para a compilação de páginas não era compatível com usuários que usam o proxy HTTP.

Um número significativo de erros 503 foram registrados toda vez que um usuário visitou a página /settings de um repositório se o gráfico de dependência não estava habilitado.

Os repositórios internos só foram retornados quando o usuário tinha afiliações com o repositório por meio de uma equipe ou por meio do status de colaborador, ou consultado o parâmetro ?type=internal.

Os trabalhos em segundo plano falharam tiveram tentativas ilimitadas que poderiam causar grandes filas muito grandes.

Um número significativo de erros de 503 estavam sendo criados se o trabalho programado para sincronizar vulnerabilidades com o GitHub tentasse executar quando o gráfico de dependência não foi habilitado e a análise de conteúdo foi habilitada.

Quando o GitHub Actions é habilitado sem executar backups regulares programados, o registro de transações do MSSQL pode crescer de forma ilimitada e pode consumir todo o espaço disponível no disco de dados do aparelho, causando uma possível interrupção.

Se você configurou backups do MSSQL regulares, não é necessária nenhuma ação adicional. Caso contrário, se você tiver GitHub Actions habilitado anteriormente, execute os seguintes comandos depois de instalar este patch.

ghe-actions-console -s -c 'Update-Service -Force'
ghe-actions-console -s Token -c 'Update-Service -Force'
ghe-actions-console -s Actions -c 'Update-Service -Force'

Os registros para babeld agora incluem um campo cmd para solicitações de publicidade de ref de HTTP em vez de apenas incluí-lo durante as solicitações de negociação.

ALTO: Uma vulnerabilidade transversal de caminho foi identificada no GitHub Enterprise Server que pode ser explorada ao construir um site do GitHub Pages. As opções de configuração controladas pelo usuário usadas pelo GitHub Pages não eram suficientemente restritas e possibilitaram a leitura de arquivos na instância do GitHub Enterprise Server. Para explorar essa vulnerabilidade, um invasor precisará de permissão para criar e construir um site do GitHub Pages na instância do GitHub Enterprise Server. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server antes da versão 3.1.3 e recebeu um CVE-2021-22867. Esta vulnerabilidade foi relatada por meio do do programa de Compensação de Erros do GitHub.

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

A variável de data de vencimento do SAML não era configurável.

Os serviços do aplicativo falhariam as suas verificações de saúde durante a configuração fossem aplicadas antes de poderem entrar em um estado saudável.

ghe-cluster-config-node-init falharia durante a configuração do cluster se o proxy HTTP estiver habilitado.

Os hooks de pre-receive podem encontrar um erro Failed to resolve full path of the current executable due to /proc não sendo montado no container.

O Collectd não resolveria o nome de host de destino após a inicialização.

O trabalho que os repositórios obsoletos excluídos pode não conseguir progredir se alguns desses repositórios estiverem protegidos da exclusão por retenção legal.

Os Trabalhos de fundo estavam sendo enfileirados na fila spam que não estavam sendo processados.

O método de merge preferido seria redefinido ao tentar novamente após um merge de PR falhada.

Os pushes do Git podem gerar um erro de 500 servidor interno durante o processo de reconciliação do usuário em instâncias usando o modo de autenticação do LDAP.

Após a atualização de 3.0.x para 3.1.x, em alguns casos o GitHub Actions falharia com um erro: An unexpected error occurred when executing this workflow.

Aprimorou-se a eficiência da aplicação da configuração ao ignorar as regras de firewall para permitir IP, que não haviam sido alteradas, o que economizou tempo significativo em grandes clusters.

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

Um grande número de métricas gauge-dependency-graph-api-dispatch_dispatch poderiam acumular-se no Console de Gerenciamento.

O serviço sshd � s vezes falharia em iniciar instâncias em execução na Google Cloud Platform.

Arquivos de atualização antigos continuariam no disco do usuário, gerando, � s vezes, falta de espaço.

gh-migrator exibiu um caminho incorreto para a saída do registro.

Um arquivo de exportação falharia silenciosamente em importar pull requests se contivessem solicitações de revisão de equipes ausentes no arquivo.

Atualize a versão do executor de GitHub Actions no GHES 3.1 para v2.278.0

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

Os clientes SVN 1.7 e os mais antigos mostraram um erro ao usar os comandos svn co e svn export.

Acessar um repositório por meio do shell administrativo usando ghe-repo <owner>/<reponame> geraria atraso.

Após a atualização, usuários experimentaram uma redução de disponibilidade durante o uso intensivo, porque os serviços reiniciaram com muita frequência. Isto ocorreria devido a incompatibilidade de tempo entre a configuração nómada e a dos serviços internos.

Em algumas instâncias, executar o ghe-repl-status após configurar o GitHub Actions produziria um erro e o ghe-actions-teardown falharia.

O arquivo ghe-dbconsole retornaria erros em algumas circunstâncias.

Importar falhas de organizações ou repositórios de fontes que não são do GitHub podem produzir um erro undefined method '[]' for nil:NilClass.

Nomes de perfis do GitHub podem ter mudado involuntariamente ao usar a autenticação SAML, se o nome de perfil do GitHub não corresponder ao valor do atributo mapeado para o campo Full name no Console de Gerenciamento.

A atualização de uma instância que havia executado anteriormente uma versão de 2.13, e não uma versão 2.14, gerou um erro de migração do banco de dados relacionado �  transição de dados AddRepositoryIdToCheckRuns.

Os usuários da API do GraphQL podem consultar o campo público 'closingIssuesReferences' no objeto 'PullRequest'. Este campo recupera problemas que serão automaticamente fechados quando o pull request relacionado for mesclado. Esta abordagem permitirá também que estes dados sejam migrados no futuro, como parte de um processo de migração de fidelidade mais elevado.

[Digitalização de segredo]� (https://github.com/features/security) está disponível em GitHub Enterprise Server 3,1+. Faça a digitalização de repositórios públicos e privados para obter credenciais comprometidas, encontre segredos e notifique o provedor ou administrador do segredo no momento em que fore comprometidos em um repositório.

Esta versão inclui várias melhorias do beta da Digitalização de Segredo em GitHub Enterprise Server:

• Expandiu nossa [cobertura de padrão](/enterprise-server@3.1/code-security/secret-security/about-secret-scanning#about-secret-scanning-for-private-repositories de 24 a 37 parceiros
• Adicionado um API e [webhooks](/developers/webhooks-and-events/webhook-events-and-payloads#secret_scanning_alert <1>)
• Adicionado notificações para autores de commit quando eles fazem commit de segredos
• Atualizou a visão do índice para facilitar a triagem de segredos em massa
• Reduziu a taxa de falso-positivo em muitos padrões

Os administradores que usam Segurança Avançada GitHub podem hbilitar e configurar a digitalização de segredo de Segurança Avançada GitHub. Você pode revisar os requisitos mínimos atualizados para sua plataforma antes de habilitar a digitalização de segredo de Segurança Avançada GitHub.

Esta versão inclui várias melhorias para a cobrança de Segurança Avançada GitHub em GitHub Enterprise Server:

• Agora, os clientes de Segurança Avançada GitHub podem visualizar a contagem do seu committer ativo e o número restante de estações do committer não utilizadas na página de Cobrança da conta corporativa da sua organização ou empresa. Se a segurança avançada for comprada para uma empresa, os administradores também poderão ver as estações dos committers ativos que são utilizadas por outras organizações dentro da sua empresa. Para obter mais informações, consulte "Sobre a licença de segurança avançada no GitHub" e "Visualizando seu uso de segurança avançada no GitHub.
• Os clientes do GitHub Advanced Security agora podem ver a contagem ativa de committer para qualquer repositório habilitado para segurança avançada na página de cobrança da conta da sua organização ou empresa. Essas alterações ajudam os administradores a rastrear sua utilização para quantas licenças de committer compraram. Para obter mais informações, consulte "Gerenciar configurações de segurança e análise para sua organização."

Esta versão inclui melhorias para alertas do Dependabot em GitHub Enterprise Server:

• Os usuários com alertas do Dependabot habilitados podem ver quais dos seus repositórios são impactados por uma determinada vulnerabilidade, acessando a sua entrada no banco de dados de Consultoria do GitHub. Este recurso está disponível na versão beta pública. Para mais informações, consulte "Visualizar e atualizar dependências vulneráveis no seu repositório."
• Quando uma vulnerabilidade é adicionada ao banco de dados de Consultoria do GitHub, você não receberá mais notificações de e-mail e web para alertas de dependência em vulnerabilidades de severidade baixa e moderada. Estes alertas ainda podem ser acessados na aba Segurança do repositório. Para obter mais informações, consulte "[Visualizar e atualizar dependências vulneráveis no seu repositório](/enterprise-server@3.1/code-security/supply chain-security/viewing-and-updating-vulnerable-dependencies-in-your-repository).
• Agora você pode dar instruções � s pessoas sobre como relatar, de forma responsável, vulnerabilidades de segurança no seu projeto, adicionando um arquivo SECURITY.md �  pasta root, docs ou .github do seu repositório. Quando alguém criar um problema no seu repositório, a pessoa verá um link para a política de segurança do seu projeto. Para obter mais informações, consulte "Adicionar uma política de segurança ao seu repositório."

GitHub Actions agora pode gerar um gráfico visual do seu fluxo de trabalho a cada execução. Com a visualização de fluxo de trabalho, você pode:

• Ver e entender complexos fluxos de trabalho
• Acompanhar o progresso dos fluxos de trabalho em tempo real
• Solucionar problemas rapidamente acessando facilmente logs e metadados de tarefas
• Monitorar o progresso das tarefas de implantação e acessar facilmente metas de implantação

Para obter mais informações, consulte "Usando o gráfico de visualização".

A Concessão de autorização de dispositivo do OAuth 2.0 permite que qualquer ferramenta de cliente CLI ou desenvolvedor efetue a autenticação usando um sistema secundário com um navegador.

Os administradores que usam aplicativos OAuth e aplicativos GitHub podem [habilitar e configurar] o fluxo de autorização do dispositivo OAuth 2.0, além do fluxo de autorização do aplicativo web existente. Você pode revisar os requisitos mínimos atualizados para sua plataforma antes de habilitar o fluxo de autorização do dispositivo do OAuth 2.0.

Com o merge automático, os pull requests podem ser configurados para merge automaticamente quando todos os requisitos de merge forem satisfeitos. Isto evita que os usuários precisem verificar constantemente o status dos seus pull requests apenas para fazer o merge. O merge automático pode ser habilitado por um usuário com permissão para merge e em pull requests que possuem requisitos de merge não satisfeitos. Para obter mais informações, consulte "[Efetuar merge automaticamente de um pull request](/enterprise-server@3.1/github/collaborating-with-issues-and-pull-requests/automaticamente, merging-a-pull-request)."

Você pode personalizar os tipos de notificações que deseja receber de repositórios individuais. Para obter mais informações, consulte "Configurar notificações."

GitHub Mobile o filtro permite que você procure e encontre problemas, pull requests e discussões do seu dispositivo. Novos metadados para problemas e itens da lista de pull request permitem que você filtre por responsáveis, verifique status, status de revisão e contagens de comentários.

A beta de GitHub Mobile está disponível para GitHub Enterprise Server. Efetue o login com os nossos aplicativos de Android e iOS para triar as notificações e gerenciar problemas e pull requests em qualquer lugar. Os administradores podem desabilitar o suporte móvel para sua empresa usando o console de gerenciamento ou executando o ghe-config app.mobile.enabled false. Para mais informações, consulte "GitHub Mobile."

Ao pré-calcular as comprovações, a quantidade de tempo que um repositório está sob o bloqueio foi reduzida drasticamente, o que permitiu mais operações de escrita com sucesso e melhorando o desempenho do monorrepositório.

A versão mais recente do CLI do CodeQL é compatível com o upload dos resultados da análise para o GitHub. Isso facilita a execução da análise de código para clientes que desejem usar sistemas de CI/CD diferentes de GitHub Actions. Anteriormente, esses usuários tinham de usar o executor do CodeQL separado, que continuará disponível. Para obter mais informações, consulte "Sobre o escaneamento de código CodeQL no seu sistema de CI."

GitHub Actions agora é compatível com a ação de ignorar os fluxos de trabalho push e pull_request, ao procurar algumas palavras-chave comuns na sua mensagem de commit.

Serão arquivadas as anotações com mais de quatro meses de anotações de verificação.

A escala de alocação do trabalhador para tarefas de fundo foi revisada. Recomendamos validar se os novos padrões são apropriados para sua carga de trabalho. As substituições de trabalho em segundo plano devem ter sua definição cancelada na maioria dos casos. [Atualizado em 2022-03-18]

Após o feedback, a exibição dos resultados de digitalização de código em um pull request sem envio com um ID de pull request continuará sendo compatível. Para obter mais informações, consulte "[Configurando a digitalização de código](/enterprise-server@3. /code-security/secure-coding/configuring-code-scanning#scanning-pull-requests)" e "Configurando digitalização de código do CodeQL no seu sistema de CI.

Suporte ao upload do SARIF ampliado para um máximo de 5000 resultados por upload.

Você pode especificar várias URLs de retorno de chamada ao configurar um aplicativo GitHub. Isso pode ser usado em serviços com vários domínios ou subdomínios. O GitHub sempre negará a autorização se a URL do retorno de chamada da solicitação não estiver na lista de autorização de URL de retorno de chamada.

A permissão de arquivo do aplicativo GitHub foi atualizada para permitir que um desenvolvedor do aplicativo especifique até 10 arquivos para acesso somente leitura ou leitura e gravação que o aplicativo pode solicitar acessar.

O CodeQL agora é compatível com mais bibliotecas e estruturas para uma série de linguagens (C++, JavaScript, Python,Java, Go). O mecanismo do CodeQL agora pode detectar mais fontes de dados de usuário não confiáveis, o que melhora a qualidade e profundidade dos alertas de digitalização de código "Sobre o CodeQL."

Ao configurar um aplicativo GitHub, a URL da chamada de retorno de autorização é um campo obrigatório. Agora, permitimos que o desenvolvedor especifique várias URLs de chamada de retorno. Isso pode ser usado em serviços com vários domínios ou subdomínios. O GitHub sempre negará a autorização se a URL da chamada de retorno da solicitação não estiver na lista da URL da chamada de retorno da autorização.

Exclua um diretório inteiro de arquivos, incluindo subdiretórios, do seu navegador da web. Para obter mais informações, consulte "Excluindo um arquivo ou diretório."

Inclua várias palavras depois de # em um problema, discussão ou comentário de pull request para restringir ainda mais a sua pesquisa.

Quando você estiver escrevendo um problema, um pull request ou um comentário sobre a sintaxe da lista de itens, os números e tarefas são preenchidos automaticamente depois que você pressionar return ou enter.

A API de digitalização de código permite que os usuários façam o upload de dados sobre resultados de testes de segurança de análise estática ou exportem dados sobre alertas. Para obter mais informações, consulte a API de digitalização de código.

A API dos aplicativos GitHub para o gerenciamento de instalações agora se foi atualizada de uma pré-visualização de API para uma API geralmente disponível. O cabeçalho de pré-visualização não é mais necessário para acessar esses pontos de extremidades.

MÉDIO Em certas circunstâncias, os usuários que foram removidos de uma equipe ou organização poderiam manter acesso de escrita a branches para os quais tinham aberto um pull request.

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

Todos os problemas conhecidos do Candidato 1 foram corrigidos, exceto aqueles listados na seção Problemas Conhecidos abaixo.

Na página "Configurar Ações e Pacotes" do processo inicial de instalação, clicando no botão "Configurações do domínio de teste" não realizou o teste.

A execução de ghe-btop falhou com um erro de que não foi possível encontrar um contêiner babeld.

O MySQL poderia recarregar e gerar tempo de inatividade se você alterar as configurações automáticas de falha.

Após a atualização, uma incompatibilidade de valores de tempo limite interno e externo criou indisponibilidade do serviço.

Atrasos de replicação esperados nos avisos gerados pelo MSSQL.

O link para "Configurando clustering" no Console de Gerenciamento estava incorreto.

Ao criar ou editar um hook pre-receive, uma condição de corrida na interface de usuário significava que, depois de selecionar um repositório, os arquivos dentro do repositório � s vezes não foram preenchidos no menu suspenso de arquivos.

Quando um endereço IP é adicionado a uma lista de permissões usando o botão "Criar Entrada da Lista de Permissões", ele ainda poderia ser exibido como bloqueado.

As referências ao "gráfico de dependência" e aos "alertas de dependência" não foram mostradas como desabilitadas em alguns repositórios.

Configurar um anúncio nas configurações da conta corporativa pode gerar um erro 500 de servidor interno.

As solicitações de HTTP POST para o ponto de extremidade /hooks podem falhar com uma resposta 401 devido a um hookID configurado incorretamente.

O processo build-server falhou ao limpar os processos deixando-os no estado 'defunct'.

spokesd criou entradas de registro excessivas incluindo a frase "fixing placement skipped".

Ao atualizar ações a, atualização pode falhar se a instância não puder fazer autorrequisições por meio do nome de host configurado.

A atualização de 2.22.x para 3.1.0.rc1 pode resultar em um erro de migração de banco de dados relacionado �  transição de dados BackfillIntegrationApplicationCallUrlsTransition.

Demoraremos para ter acesso a um repositório por meio do shell administrativo usando ghe-repo <owner>/<reponame>. Como uma alternativa, use ghe-repo <owner>/<reponame> -c "bash -i" até que uma correção esteja disponível na próxima versão.

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.

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

As regras personalizadas de firewall não são mantidas durante uma 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 tem mais de 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.

A atualização de uma instância que havia executado anteriormente uma versão de 2.13, e não uma versão 2.14, gerou um erro de migração do banco de dados relacionado �  transição de dados AddRepositoryIdToCheckRuns.

Após a atualização de 3.0.x para 3.1.x, em alguns casos, o GitHub Actions pode falhar com um erro: `Um erro inesperado ocorreu ao executar este fluxo de trabalho. Para contornar esse problema, conecte ao shell administrativo (ssh) e execute:

ghe-actions-console -s ações -c "Queue-ServiceJob -JobId 4DB1F4CF-19FD-40E0-A253-91288813DE8B"

Quando um nó de réplica está off-line em uma configuração de alta disponibilidade, GitHub Enterprise Server ainda pode encaminhar solicitações de GitHub Pages para o nó off-line, reduzindo a disponibilidade de GitHub Pages para os usuários.

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.20 tornou-se obsoleto em 2 de março 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.21 irá tornar-se obsoleto em 9 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.

Começando com GitHub Enterprise Server 2.21.0, dois eventos legados de webhook relacionados a aplicativos GitHub foram descontinuados e serão removidos em GitHub Enterprise Server 3.2.0. Os eventos obsoletos integration_installation e integration_installation_repositories têm eventos equivalentes que serão compatíveis. Mais informações estão disponíveis no post do blogue de anúncio de obsolescência.

Começando com GitHub Enterprise Server 2.21, o ponto de extremidade do legado dos aplicativos GitHub para a criação de tokens de acesso de instalação foi suspenso e será removido em GitHub Enterprise Server 3.2.0. Mais informações estão disponíveis no post do blogue de anúncio de depreciação.

O GitHub não é compatível mais com os pontos de extremidade do aplicativo OAuth que contêm access_token como um parâmetro de caminho. Nós introduzimos novos pontos de extremidade que permitem que você gerencie, com segurança, tokens para aplicativos OAuth movendo access_token para o texto da solicitação. Embora obsoleto, os pontos de extremidade ainda podem ser acessados nesta versão. Queremos remover esses pontos de extremidade em GitHub Enterprise Server 3.4. Para obter mais informações, consulte post do blogue de anúncio de depreciação.

GitHub Actions removerá o suporte para ações de referência usando a versão encurtada de um commit SHA do Git. Isso pode fazer com que alguns fluxos de trabalho no seu repositório sejam interrompidos. Para corrigir esses fluxos de trabalho, você deverá atualizar a referência de ação para utilizar o SHA do commit completo. Para obter mais informações, consulte "Enrijecimento de segurança para GitHub Actions."

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.

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]