Enterprise Server 2.22 release notes

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

The GitHub Connect configuration of the source instance was always restored to new instances even when the --config option for ghe-restore was not used. This would lead to a conflict with the GitHub Connect connection and license synchronization if both the source and destination instances were online at the same time.

Fixes GitHub Pages builds so they take into account the NO_PROXY setting of the appliance. This is relevant to appliances configured with an HTTP proxy only.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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.

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.

Atraso de replicação normal nos avisos gerados pelo MSSQL.

Um endereço IP adicionado por um administrador usando o botão "Criar Entrada da Lista Branca" ainda poderia ser bloqueado.

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

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

ALTO: Uma vulnerabilidade com interpretação incorreta da interface do usuário foi identificada no GitHub Enterprise Server, que habilitou mais permissões durante o fluxo web de autorização de usuários do aplicativo GitHub do que foram exibidas para o usuário durante a aprovação. Para explorar essa vulnerabilidade, um invasor precisa criar um aplicativo GitHub na instância e fazer com que um usuário autorize o aplicativo por meio do fluxo de autenticação web. Todas as permissões concedidas seriam exibidas corretamente durante a primeira autorização, porém, em certas circunstâncias, Se o usuário revisitar o fluxo de autorização após o aplicativo GitHub configurar permissões adicionais de nível de usuário, é possível que essas permissões adicionais não sejam exibidas, fazendo com que sejam concedidas mais permissões do que o usuário potencialmente pretendia. Esta vulnerabilidade afetou o GitHub Enterprise Server 3.0.x antes da versão 3.0.7 e 2.22.x e 2.22.13. Isso foi corrigido nas versões 3.0.7 e 2.22.13. Um CVE-2021-22866 foi atribuído a esta vulnerabilidade e foi relatada por meio do Programa de Recompensa de Erro do GitHub.

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

A falha automática do orquestrador poderia ser habilitada durante a fase de configuração.

Usuários com permissões de mantenedor para um repositório foram mostrados um aviso de verificação de e-mail em vez de uma compilação de páginas bem sucedida na página de configurações do repositório.

O proprietário do código de uma regra curinga seria adicionado incorretamente à lista de proprietários para o selo do código mesmo se uma regra posterior tivesse prioridade para esse caminho.

A documentação do OpenAPI referia-se a um cabeçalho inválido.

Registro adicionado para mudança de configuração na recarga do HAProdi.

Registro adicionado para criação de repositório.

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

Durante as atualizações, o processo seria pausado indefinidamente após de cleanup nomad job.

Um 'ghe-cluster-failover' falhou com a mensagem de erro 'Trilogy::Error: trilogy_connect'.

ghe-cluster-status-mysql mostrou avisos de falhas como erros.

O script de configuração em execução na replicação do MySQL pode ter causado uma ressemeadura desnecessária do banco de dados durante a falha do banco de dados.

O arquivo config-apply pode levar mais tempo do que o necessário devido ao chamado desnecessário de rake db:migrate.

O Orchestrator poderia ter falhado para uma réplica do MySQL que não estava sendo replicada a partir do primário durante a fase de semeadura quando não era possível conectar o primário.

Organizações ou projetos com erros bloquearam a migração e não puderam ser excluídos.

Os clientes com mais de três hosts de armazenamento não conseguiram restaurar seu cluster de recuperação de catástrofes devido à seleção dos mais completos discos em vez de nós vazios.

Verificações de preliminares permitem todos os tipos de instância de AWS por padrão.

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

Uma mensagem de aviso jq: error (at <stdin>:0): Cannot index number with string "settings"pode ocorrer durante a réplica de promoção.

A restauração contínua de backups para um cluster pode falhar devido a falhas na conexão com o primário.

O destaque de sintaxe pode falhar devido à falta de memória do contêiner de Treelights.

O acesso à página /settings/emails armazenaria o estado que pode causar redirecionamentos impróprios ao efetuar o logout e o login novamente.

Os alertas de gráfico de dependência não foram exibidos para alguns componentes cujos consultores têm nomes de pacotes maiúsculos em vulnerable_version_ranges.

Os aplicativos de integração do GitHub não foram capazes de notificar equipes quando mencionadas diretamente por meio de uma menção em um comentário do problema.

Quando o ghe-migrator encontrou erros na importação, às vezes abortaria todo o processo e os logs não incluíam contexto suficiente.

ALTO: Uma vulnerabilidade de controle de acesso imprópria foi identificada no GitHub Enterprise Server, que permitiu o acesso a tokens gerados a partir do [fluxo de autenticação web] aplicativo GitHub] (https://docs.github.com/en/developers/apps/identifying-and-authorizing-users-for-github-apps#web-application-flow) para ler os metadados do repositório privado por meio da API REST sem ter sido concedida as permissões adequadas. Para explorar essa vulnerabilidade, um invasor precisa criar um aplicativo no GitHub na instância e ter um usuário autorizando o aplicativo através do fluxo de autenticação web. Os metadados do repositório privado retornados seriam limitados aos repositórios pertencentes ao usuário identificados pelo token. Esta vulnerabilidade afetou todas as versões do GitHub Enterprise Server antes da versão 3.0.4 e foi corrigida nas versões 3.0.4, 2.22.10, 2.21.18. A esta vulnerabilidade foi atribuída CVE-2021-22865 e foi relatada por meio do Programa de Recompensa de Erro do GitHub.

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

Um fuso horário definido no GitHub Enterprise 11.10.x ou mais cedo não estava sendo usado por alguns serviços que tinham o fuso horário UTC.

Os serviços não estavam sendo transferidos para novos arquivos de registro como parte da rotação de registro, resultando em aumento no uso do disco.

A etiqueta nos resultados de pesquisa para repositórios internos foi mostrada como "Privado" em vez de "Interno".

ALTO: 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. As opções de configuração controladas pelo usuário usadas pelo GitHub Pages não eram suficientemente restritas e possibilitaram a substituição de variáveis de ambiente levando à execução do código 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 de 3.0.3 e foi corrigida em 3.0.3, 2.22.9 e 2.21.17. Esta vulnerabilidade foi relatada por meio do programa de Recompensas de Erro do GitHub e recebeu o CVE-2021-22864.

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

Executar ghe-cluster-config-init poderia fazer com que um cluster se tornasse inoperante.

O sistema pode perder a faixa do PID do HAProxy.

O aviso de falha do mysql-over foi exibido indefinidamente após uma falha bem-sucedida.

A execução do ghe-cluster-config-init não era totalmente contabilizada pelo código de saída de trabalhos em segundo plano, o que gerou a manipulação imprópria de verificações de precursores.

Um link Segurança & Análise não foi exibido na navegação do lado esquerdo na página de Configurações para repositórios.

Após desabilitar os pacotes do GitHub, algumas páginas da organização retornariam uma resposta de HTTP 500 error.

Melhora a confiabilidade dos serviços nomad implementando a mesma política de reinicialização introduzida no GitHub Enterprise Server 3.0.

Use a relative number for consul and nomad bootstrap_expect allowing for a cluster to bootstrap even if a handful of nodes are down.

Os registros irão girar com base no tamanho e tempo.

Adicionado kafka-lite ao comando ghe-cluster-status.

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

Registros de jornais do Systemd foram duplicados em vários lugares.

Um administrador do site poderia obter uma página de com a mensagem "500 error" ao tentar visualizar problemas referenciados em repositórios privados.

Importar arquivos do repositório do GitHub Enterprise Server sem arquivos do repositório irá falhar com um erro.

ALTO: Uma vulnerabilidade de controle de acesso imprópria foi identificada no GitHub Enterprise Server, o que permitiu que usuários autenticados da instância obtivessem acesso de gravação a repositórios não autorizados por meio de solicitações especificamente elaboradas e solicitações da API REST. Um invasor precisaria ser capaz de bifurcar o repositório de destino, uma configuração desabilitada por padrão para repositórios privados pertencentes à organização. As proteções de branch como revisões de pull request requeridas ou verificações de status impediriam que commits não autorizados fossem mesclados sem revisão ou validação. A essa vulnerabilidade foi atribuída a CVE-2021-22861. Esse problema foi relatado por meio do Programa de Recompensas de Erros do GitHub.

ALTO: Uma vulnerabilidade de controle de acesso imprópria foi identificada na API do GraphQL do GitHub Enterprise Server, o que permitiu que usuários autenticados da instância modificassem a permissão de colaboração do mantenedor de um pull request sem autorização adequada. Explorando essa vulnerabilidade, um invasor seria capaz de obter acesso aos branches principais dos pull requests abertos em repositórios dos quais são mantenedores. A bifurcação de repositórios está desabilitada por padrão para repositórios privados de propriedade da organização e impediria esta vulnerabilidade. Além disso, as proteções de branches, como revisões de pull request necessárias ou verificações de status impediriam que commits não autorizados fossem mesclados sem outras revisões ou validações. Essa vulnerabilidade foi atribuída a CVE-2021-22863. Esse problema foi relatado por meio do Programa de Compensação de Erro do GitHub.

ALTO: 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. A configuração controlada pelo usuário dos avaliadores usados pelo GitHub Pages não foi restrita suficientemente e permitiram a execução de comandos 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. A essa vulnerabilidade foi atribuída CVE-2020-10519 e foi relatada por meio do Programa de Recompensas por Erros do GitHub.

MÉDIO: Os tokens do GitHub Pages podem acabar em registros.

BAIXO: Uma solicitação especialmente trabalhada para a ponte SVN poderia ser acionada muito tempo antes de a falha resultar em uma negação de serviço (DoS).

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

As verificações de integridade do balanceador de carga em alguns casos poderiam fazer com que os registros do babeld fossem preenchidos erros referentes ao protocolo PROXY.

Uma mensagem informativa foi registrada involuntariamente como erro nos instantâneos dos utilitários do GitHub Enterprise Backup, o que gerou o envio de e-mails desnecessários quando os backups eram programados por trabalhos do cron que ouvem a saída para o stderr.

Ao restaurar um backup grande, o registro de exceções relacionado à exaustão de memória do Redis pode gerar falha na restauração devido a um disco completo.

Ao configurar primeiro uma nova instância, se você selecionou "Configure como Replica" você não conseguirá iniciar a replicação.

Quando o GitHub Actions foi habilitado, isso gerou uma falha no modo de manutenção no console de gerenciamento.

Ao editar uma página wiki, um usuário pode ter um erro 500 ao clicar no botão Salvar.

Um commit S/MIME assinado utilizando um certificado com vários nomes no nome alternativo do assunto seria exibido incorretamente como "Não verificado" no selo do commit.

O usuário suspenso recebeu e-mails quando adicionado a uma equipe.

O usuário visualizou a mensagem 500 error ao executar operações no git em uma instância configurada com autenticação do LDAP.

A tarefa em segundo plano "remove_org_member_package_access" ficou visível no console de gerenciamento e aumenta continuamente.

Quando um repositório teve um grande número de manifestos, foi exibido um erro `Você atingiu o número máximo de arquivos de manifesto permitidos (20) para este repositório. na aba Insights -> Fotos de dependência. Para obter mais informações, consulte Limites de visualização.

Ao fazer o upload de um novo arquivo de licença com um número diferente de estações do arquivo de licença anterior, a diferença de estações não estava corretamente representada nas configurações da conta corporativa -> página de licença.

A caixa de seleção "Evitar que os administradores do repositório alterem o acesso de leitura anônimo do Git, disponível nas configurações da conta corporativa, não pode ser habilitada ou desabilitada com sucesso.

Quando uma criação do GitHub Pages falhou, a notificação de e-mail continha um link incorreto para o local de suporte.

Durante um ano bissexto, o usuário recebeu uma resposta 404 ao tentar ver a atividade de Contribuição na segunda-feira.

Adicionou-se suporte para AWS EC2 r5b instance types.

Priorização da fila de segundo plano ajustada para distribuir trabalhos de forma mais equilibrada.

BAIXO: Alto uso da CPU pode ser acionado por uma solicitação especialmente elaborada para a ponte SVN, o que resulta em em Negação de Serviço (DoS).

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

As solicitações de alguns recursos de arquivo como um arquivo zip ou um arquivo não processado podem entrar em um loop de redirecionamento.

Um limite de tempo pode impedir que algumas pesquisas de problemas e pull requests forneçam resultados de pesquisa completos.

Abas personalizadas com caracteres não alfabéticos em telas pequenas não foram interpretadas corretamente.

Um comportamento subjacente estava causando falhas ao fazer push de conteúdo em um repositório do Git habilitado com LFS.

Em alguns casos raros, os problemas podem gerar um erro 500 quando acessados pela interface web.

O serviço de autorização foi detectado como não saudável devido a uma condição de raça no bootstrap que gerou a reinicialização do serviço.

O processo de atualização do Elasticsearch não foi capturado pelo ghe-diagnostics.

Habilitar o GitHub Actions em uma configuração atualizada de alta disponibilidade gerou erros na replicação.

Um comportamento subjacente fez com que um serviço se tornasse indisponível durante o processo de atualização do hotpatch

Os usuários que se conectam a uma réplica ativa receberiam um erro ao conectar ao websocket das atualizações ao vivo.

Um subconjunto de registros de encaminhamento de certificados SSL não foi aplicado corretamente.

Notificações de e-mail enviadas aos usuários suspensos quando foram removidos de uma equipe ou de uma organização.

A forma como os certificados SSH foram aplicados entre organizações e empresas foi inconsistente.

Quando uma conta teve o limite de taxa limitado devido ao uso de senhas incorretas, ela pôde ser bloqueada por até 24 horas.

A sincronização de pull request em repositórios com muitas referências pode fazer com que as filas de trabalhador sejam atrasadas.

Ao fazer login com um nome de usuário e senha local (autenticação integrada) após tentar visitar uma página específica, o usuário foi direcionado para a página inicial em vez de ser direcionado para o seu destino pretendido.

Para instâncias de GHES que usam autenticação integrada com um provedor de identidade do SAML interno, os usuários sem um endereço de e-mail associado não podem criar um commit a partir da interface web.

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

Os logs de babeld não tinham um separador entre segundos e microssegundos.

Após atualizar o GHES com um hotpatch, os comandos ghe-actions-precheck e ghe-packages-precheck falhariam com o erro "docker load" accepts no arguments.

Quando a política de "alteração de visibilidade do repositório" na conta corporativa foi definida como "Habilitada", os proprietários da organização não conseguiram alterar a visibilidade dos repositórios na organização.

Os logs de auditoria podem ser atribuídos a 127.0.0.1 em vez do endereço IP da fonte real.

BAIXO: O alto uso da CPU pode ser acionado por uma solicitação especialmente elaborada para a ponte SVN, gerando Negação de Serviço (DoS) no serviço da ponte SVN. (atualizado 2020-11-16)

BAIXO: A validação incorreta de token gerou uma entropia reduzida para os tokens de correspondência durante a autenticação. A análise mostra que, na prática, não há risco significativo de segurança aqui.

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

O GitHub Actions pode falhar ao iniciar com êxito caso tenha sido habilitado previamente em uma instância com execução 2.22.0 e caso tenha sido atualizado para a 2.22.1 ou 2.22.2

Os arquivos de configuração para o GitHub Actions não foram copiados para a réplica ao configurar as réplicas de alta disponibilidade, gerando, potencialmente erros durante ghe-repl-promote.

Em uma nova instância com a configuração 2.22.1 ou 2.22.2 ou após a atualização para 2.22.1 ou 2.22.2, o feed de atividades no painel de uma organização não seria atualizado.

Editar templates de problemas com nomes de arquivos que contenham caracteres diferentes de ASCII gerariam uma falha com um "500 Internal Server Error".

Um método métrico de coleta em segundo plano para aumentar a utilização da CPU. (atualizado 2020-11-03)

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

Se as configurações da conta de armazenamento não conseguiram validar ao configurar as ações do GitHub, a execução de ghe-actions-teardown foi necessária antes de fazer uma nova tentativa.

Uma configuração de proxy personalizada pode afetar negativamente o ambiente do GitHub Actions.

Em uma mudança de endereço no eth0, o Nomad e o Cônsul poderiam ficar sem resposta.

Ao usar certificados autosassinados, o GHES pode ter exceções de validação SSL na configuração do GitHub Actions.

O uso de uma ação do GitHub de um branch com um caractere + ou / gerou um erro: Unable to resolve action.

A mensagem da conta corporativa "Confirmar requisito de dois fatores" estava incorreta.

Em certas solicitações acima de 100 MB, o buffer de Kafka pode ser sobre-alocado.

MÉDIO: ImageMagick foi atualizado para o endereço DSA-4715-1.

As solicitações de uma integração do aplicativo GitHub para atualizar um token de acesso do OAuth seriam aceitas se forem enviadas com um Id de cliente e segredo de cliente do OAuth diferente e válido que foram usados para criar o token de atualização.

Um usuário cujo nome de usuário de diretório de LDAP padronizado em um login da conta GHES existente pode efetuar a autenticação na conta existente.

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

O menu suspenso de formato do ID do nome no Console de Gerenciamento seria redefinido para "não especificado" depois de configurá-lo como "persistente".

A atualização que usa um hotpatch pode falhar com um erro: 'libdbi1' was not found

Salvar as configurações por meio do console de gerenciamento acrescentaria uma nova linha aos arquivos certificado TLS/SSL e chave que acionou o recarregamento desnecessário de alguns serviços.

Os logs do sistema para o gráfico de dependência não estavam girando, permitindo um crescimento no armazenamento ilimitado.

O gráfico de desempenho do MS SQL Server mostrou estatísticas da instância primária, mesmo quando uma réplica foi selecionada.

ghe-actions-precheck irá sair silenciosamente sem executar as verificações de armazenamento se as Ações não foram habilitadas.

A atualização poderia falhar se a configuração de substituição dos trabalhadores resgatados estiver em uso.

Alguns serviços em execução em contêineres não enviaram registros para o jornal.

Os links para as Consultorias de Segurança GitHub usariam uma URL com o nome de host da instância do GitHub Enterprise Server em vez do GitHub.com, direcionando o usuário para uma URL inexistente.

Ao importar um repositório com "ghe-migrator" poderá gerar uma exceção inesperada quando os dados inconsistentes estão presentes.

A página de configurações de segurança da conta corporativa mostrou um link para "Visualizar as configurações atuais das organizações" para a configuração da "Autenticação de dois fatores" quando o modo de autenticação em uso não é compatível com autenticação de dois fatores.

Os tokens de atualização do OAuth seriam removidos prematuramente.

A pesquisa tarefas de reparo geraria exceções durante a fase de migração da configuração.

Na página de configurações dos aplicativos GitHub, a aba "Funcionalidades Beta" não estava visível em algumas circunstâncias.

Ao usar "ghe-migrator" para importar solicitações de revisão de PR, os registros associados com usuários excluídos resultariam em registros estranhos do banco de dados.

Ao importar usuários com "ghe-migrator", ocorreria o erro de "E-mail é inválido" se o endereço de e-mail gerado pelo sistema tivesse mais de 100 caracteres.

Registrar a atividade do webhook poderia usar uma grande quantidade de espaço no disco e fazer com que o disco raiz ficasse cheio.

Os usuários experimentaram desempenho mais lento de recuperação de clone do Git em uma instância com réplicas de alta disponibilidade devido às leituras serem encaminhadas para um nó diferente.

A página de Configurações do repositório de um repositório para um usuário ou organização de sites do GitHub Pages falharia com um "500 Internal Server Error".

As operações de manutenção da rede de repositório podem ficar presas no estado "em execução".

O fato de um repositório ser excluído imediatamente após o upload da varredura de um código pode haver gerado uma parada no processamento dos resultados dos resultados de verificação de código para todos os repositórios.

Quando um grande número de resultados de verificação de código foi enviado ao mesmo tempo, o tempo de processamento de lotes pode expirar, gerando uma parada no processamento dos resultados de varredura do código.

Criar um aplicativo GitHub a partir de um manifesto falhará.

O nomes de usuário do GitHub foram alterados involuntariamente ao usar a autenticação do SAML, quando o nome de usuário do GitHub não correspondeu ao valor do atributo mapeado com o campo username no Console.

O suporte é adicionado ao tipo de instância do AWS EC2 m5.16xlarge.

Remova o requisito de impressões digitais SSH nos arquivos "ghe-migrator", pois ele sempre pode ser computado.

Os manifestos do aplicativo GitHub agora incluem o campo "request_oauth_on_install".

GitHub Actions é uma solução poderosa e flexível para CI/CD e automação de fluxo de trabalho. O GitHub Actions no Enterprise Server inclui ferramentas que ajudam você a gerenciar o serviço incluindo métricas chave no Console de Gerenciamento, logs de auditoria e controles de acesso para ajudar você a controlar a implementação.

Você precisará fornecer seu próprio storage e executores para o GitHub Actions. AWS S3, Azure Blob Storage e MinIO são compatíveis. Revise os requisitos mínimos atualizados para sua plataforma antes de ativar o GitHub Actions. Para saber mais, entre em contato com a equipe do GitHub Sales ou inscreva-se para o beta.

GitHub Packages é um serviço de hospedagem de pacotes, integrado nativamente com as APIs, ações e webhooks do GitHub. Crie um [fluxo de trabalho de ponta a ponta para o DevOps](https://docs.github.com/en/enterprise/2. 2/admin/pacotes/configuring-packages-support-for-your-enterpris) que inclui seu código, integração contínua e soluções de implantação.

Os backends de armazenamento compatíveis incluem AWS S3 e MinIO com suporte para o Azure blob em uma versão futura. Observe que o suporte atual ao Docker será substituído por uma versão beta do novo Registro de Contêiner do GitHub na próxima versão. Revise os [requisitos mínimos atualizados para sua plataforma](https://docs.github.com/en/enterprise/2. 2/admin/installation/setting-up-a-github-enterprise-server-instance) antes de ativar o GitHub Packages. Para saber mais, entre em contato com a equipe do GitHub Sales ou [inscreva-se no beta](https://resources. ithub.com/beta-signup/).

Varredura avançada de código de segurança do GitHub é um ambiente de teste de segurança para aplicativos estáticos nativos do GitHub nativo (SAST). Encontre facilmente vulnerabilidades de segurança antes que atinjam a produção, tudo desenvolvido pelo mais poderoso motor de análise de código do mundo: CodeQL.

Os administradores que usam a Segurança Avançada do GitHub podem inscrever-se em e [enable](https://docs.github. om/pt/enterprise/2.22/admin/configuration/configuring-code-scanning-for-your-appliance) o Beta de varredura avançada de código de segurança GitHub. Revise os [requisitos mínimos atualizados para sua plataforma](https://docs.github. om/en/enterprise/2.22/admin/installation/setting-up-a-github-enterprise-server-instance) antes de ativar a varredura avançada de código código de segurança GitHub.

Quando um [branch do cabeçalho do pull request](https://docs.github.com/en/enterprise/2. 2/usuário/github/colaboração-with-issues-and-pull-requests/about-branches#working-with-branches) é mesclado e excluído, todos os outros pull requests no mesmo repositório que apontam para este branch agora são redirecionados para o branch de base do pull request mesclado. Anteriormente, esses pull requests eram fechados.

Os administradores e usuários podem suspender o acesso de qualquer aplicativo do GitHub durante o tempo necessário e cancelar a suspensão do aplicativo no comando por meio das das Configurações e da API. Os aplicativos suspensos não podem acessar a API do GitHub ou eventos de webhook. Você pode fazer isso em vez de desinstalar um aplicativo, que cancela a autorização de todos os usuários. ''

Nós revisamos a abordagem que adotamos para agendar a manutenção da rede para repositórios, garantindo que os grandes monorrepositórios sejam capazes de evitar os estados de falha. ''

As réplicas passivas agora são [compatíveis e configuráveis nas implantações de cluster do GitHub Enterprise Server](https://docs.github.com/en/enterprise/2. 2/admin/enterprise-management/configuring-high-availability-replication-for-a-cluster). Essas alterações permitirão falhas mais rápidas, reduzindo RTO e RPO.

Para equipes excepcionalmente grandes, os administradores podem ajustar o padrão máximo de 1.500 para as listas de usuários. ''

Os trabalhadores compartilhados foram habilitados para tornar as atualizações ao vivo mais resilientes, compartilhando conexões entre as abas.

O link "Suporte ao Contato" na página de erro 50x agora vincula ao e-mail de suporte ou link configurado no Console de Gerenciamento.

Agora é possível gerenciar anúncios e datas de expiração globais pelas configurações da conta corporativa.

Agora você pode isentar certos usuários do limite de taxa da API padrão configurado no console de gerenciamento, se necessário.

Agora os administradores do repositório podem definir seus repositórios como qualquer opção de visibilidade disponível a partir de um único diálogo nas configurações do repositório. Anteriormente, você tinha de navegar por seções, botões e caixas de diálogo separadas para alternar entre público e privado e entre privado e interno.

Um novo link de configurações corporativasno menu suspenso do usuário facilita a navegação nas Configurações da Conta Corporativa.

O antigo link "Central de Adminstraão" na página de /stafftools foi removido. O link "Empresa" agora é a melhor maneira de acessar a Conta Corporativa a partir da página /stafftools page.

O item do submenu de Opções nas configurações da Conta Corporativa foi transferido da seção de Configurações para a seção de Políticas.

Acessar recursos usando um token de acesso pessoal ou chave SSH agora conta como atividade de usuário. Isso alivia os administradores do trabalho de filtrar determinados usuários dos relatórios de dormência do usuário e torna mais seguro usar o botão "Suspender todos" sem suspender, acidentalmente, usuários que acessaram o GitHub de forma apenas leitura através das APIs com um Token de Acesso Pessoal (PAT) ou chave SSH.

Os códigos de recuperação de dois fatores não podem mais ser usados durante o processo de autenticação de dois fatores. As senhas de uso único são os únicos valores aceitáveis.

Quando um usuário é conectado ao GitHub Enterprise Server através de um único logon, a seleção de visibilidade padrão do repositório é privada.

Agora os proprietários dos aplicativos GitHub podem escolher que os seus [tokens de acesso do usuário para servidor expirem após 8 horas](https://developer.github. om/changes/2020-04-30-expiring-user-to-server-access-tokens-for-github-apps/), para ajudar a aplicar rotação regular do token e reduzir o impacto de um token comprometido.

A interface de usuário do GitHub passou por uma atualização de design, e a página inicial dos repositórios foi reprojetada, incluindo um layout responsivo e uma melhor experiência de web móvel.

No menu suspenso do repositório "Clonar com SSH", os usuários agora serão notificados se não tiverem nenhuma configuração de chaves.

Agora, os commits são ordenados cronologicamente na linha do tempo do pull request e na aba commits. Esta nova ordem também é refletida na API REST de ["Lista de commits em um pull request"](https://docs.github.com/en/enterprise/2. 2/user/rest/reference/pulls#list-commits-on-a-pull-request) e no [Objeto "PullRequest"] de GraphQL (https://docs.github.com/en/enterprise/2.22/user/graphql/reference/objects#pullrequest) timeline connection.

Agora os usuários podem definir o padrão do tom de tema padrão para resultados de preenchimento automático de emojis nas áreas de texto de comentário.

Tree-sitter melhora o destaque da sintaxe e agora é a biblioteca padrão usada para análise de linguagens.

Os desenvolvedores e organizações agora podem adicionar seu nome de usuário do Twitter ao seu perfil

Pré-visualizações graduadas

As pré-visualizações a seguir agora fazem parte oficial da API:

• A API dos aplicativos GitHub e os pontos de extremidades que retornaram a propriedade performed_via_github_app não exigem mais o cabeçalho de pré-visualização [machine-man](https://developer. ithub.com/changes/2020-08-20-graduate-machine-man-and-sailor-v-previews/).
• Para adicionar e visualizar um motivo de bloqueio para um problema, você não precisa mais usar o cabeçalho de pré-visualização [sailor-v](https://developer. ithub.com/changes/2020-08-20-graduate-machine-man-and-sailor-v-previews/).

Alterações no esquema do GraphQL

• As mudanças de esquema do GraphQL incluem alterações retrocompatíveis, pré-visualizações do esquema e futuras alterações significativas.

O tipo adaptador de rede padrão do GitHub Enterprise Server para clientes do VMware foi alterado de E1000 para VMXNET3, começando com a versão 2.22.0. Ao fazer a atualização de uma versão anterior para 2.22.0 ou mais recente, se um adaptador de rede E1000 for detectado durante a verificação de pré-atualização, a seguinte mensagem será exibida na linha de comando:

AVISO: Seu aplicativo virtual está usando um adaptador de rede Intel E1000 emulado atualmente.
Para obter o desempenho ideal, atualize a configuração do computador virtual no seu host VMware para usar o VMXNET3 driver.
Prosseguir com a instalação? [s/N]

O administrador pode optar por atualizar o tipo de adaptador de rede para VMXNET3 antes ou após a atualização do GitHub Enterprise Server. O aplicativo virtual terá de ser encerrado para realizar esta alteração. Os clientes devem seguir as etapas recomendadas do VMware para [alterar a configuração do adaptador de rede da máquina virtual](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin. oc/GUID-3719A0BE-4B4A-44FF-8A21-290950918FBD.html) para VMXNET3. Observe que o VMXNET3 não será uma opção se a versão do sistema operacional do aplicativo virtual estiver definida como Other Linux (64-bit). Nesse caso, a versão do OS deve ser alterada primeiro Other Linux (64-bit) para Other 2.6.x Linux (64-bit) ou, se disponível, Debian GNU/Linux 9. Recomendamos testar essas alterações em uma [instância de preparação](https://docs.github. om/pt/enterprise-server@2.22/admin/installation/setting-up-a-staging-instance) antes de ser executada em uma produção do GitHub Enterprise Server.

A página de stafftools de equipe para visualizar o colaborador pendente mostrou um 500 Internal Server Error quando houve um convite de e-mail pendente.

A verificação de integridade do repositório na stafftools pode gerar resultados incorretos em repositórios ocupados.

Um usuário conectado que tenta aceitar um convite de e-mail poderia obter um erro 404 Not Found.

Se um usuário acessar um repositório cujo nome foi iniciado com "repositórios", ele será direcionado a aba "Repositórios" do proprietário em vez de chegar à página de visão geral do repositório.

As etiquetas na linha do tempo do painel não têm contraste suficiente.

GitHub Enterprise Server 2.19 irá tornar-se obsoleto a partir do dia 12 de novembro 2020, o que significa que não serão feitas versões de patch, ainda que para problemas críticos de segurança, após esta data. Para obter um melhor desempenho, melhoria na segurança e novas funcionalidades, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

A partir da versão GitHub Enterprise Server 2.21.0 dois eventos legados de webhook relacionados aos aplicativos GitHub tornaram-se obsoletos e serão removidos do GitHub Enterprise Server 2.25.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 do anúncio de obsolescência.

Começando com o GitHub Enterprise Server 2.21.0, o ponto de extremidade de legado dos aplicativos GitHub para criar os tokens de acesso de instalação tornou-se obsoleto e será removido no GitHub Enterprise Server 2.25.0. Mais informações estão disponíveis no [post do blogue do anúncio de obsolescência](https://developer. ithub.com/changes/2020-04-15-replacing-create-installation-access-token-endpoint/).

O GitHub não é mais compatível com 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 gerenciar com segurança tokens para aplicativos OAuth, movendo access_token para o texto da solicitação. Embora obsoletos, os pontos de extremidade ainda podem ser acessados nesta versão. Temos o objetivo de remover esses pontos de extremidades no GitHub Enterprise Server 3.4. Para obter mais informações, consulte post do blogue de anúncio de obscolescência.

O GitHub Enterprise Server 2.22 exige, pelo menos, Utilitários de Backup do GitHub Enterprise 2.22.0 para Backups e Recuperação de Desastre.