Enterprise Server 3.0 release notes

Packages have been updated to the latest security versions.

Custom pre-receive hooks could have failed due to too restrictive virtual memory or CPU time limits.

Attempting to wipe all existing configuration settings with ghe-cleanup-settings failed to restart the Management Console service.

During replication teardown via ghe-repl-teardown Memcached failed to be restarted.

During periods of high load, users would receive HTTP 503 status codes when upstream services failed internal healthchecks.

Pre-receive hook environments were forbidden from calling the cat command via BusyBox on Alpine.

The external database password was logged in plaintext.

An erroneous jq error message may have been displayed when running ghe-config-apply.

Failing over from a primary Cluster datacenter to a secondary Cluster datacenter succeeds, but then failing back over to the original primary Cluster datacenter failed to promote Elasticsearch indicies.

The Site Admin page for repository self-hosted runners returned an HTTP 500.

In some cases, GitHub Enterprise Administrators attempting to view the Dormant users page received 502 Bad Gateway or 504 Gateway Timeout response.

More effectively delete Webhook logs that fall out of the Webhook log retention window.

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

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

Resque worker counts were displayed incorrectly during maintenance mode.

Allocated memcached memory could be zero in clustering mode.

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. (update 2021-09-30)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAML expiration date variable was not configurable.

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

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

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

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

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

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

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

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

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

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

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.

Às vezes, a rotação dos logs pode interromper trabalhos em segundo plano.

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

A importação de um arquivo de exportação falharia se contivesse solicitações de revisão de equipes que ausentes no arquivo.

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

O processo de atualização pode falhar ao atualizar as ações se a instância não puder fazer autorrequisições usando seu nome de host configurado.

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.

O campo firstPatchedVersion agora está disponível nos objetos SecurityVulnerability na API GraphQL.

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.

Na página "Configurar Ações e Pacotes" do processo inicial de instalação quando um administrador clicou no botão "Configurações do domínio de teste" o teste não foi concluído.

A execução de ghe-btop falhou com um erro cannot find a 'babeld' container.

Os usuários estavam tendo indisponibilidade de serviço após a atualização devido a uma incompatibilidade de valores de tempo limite interno e externo.

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

O link para o GitHub Enterprise Clustering Guide sobre console de gerenciamento estava incorreto.

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

Referências às funcionalidades "Gráfico de Dependência" e "Alertas do Dependabot " foram exibidas em repositórios onde não foram habilitadas.

As solicitações do tipo HTTP POST no ponto de extremidade de /hooks poderia falhar com uma resposta 401 em razão de hookID ter sido 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".

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.

As citações incluídas em Ações ou pacotes de configuração de armazenamento podem causar erros.

Os hooks pre-receive personalizados podem falhar devido ao tamanho do arquivo muito restritivo ou ao número de limites abertos de arquivos.

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.

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.

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.

As atualizações não incluíram a versão mais recente do executor de ações instalado corretamente.

A configuração do github-env pode resultar em processos zumbis.

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.

O botão Criar Repositório foi desabilitado para usuários que pertenceram a mais de 50 organizações.

A exclusão de um branch geraria temporariamente uma mensagem de erro indicando que algo deu errado quando a exclusão foi bem-sucedida.

O índice rms-packages foi exibido no painel de administração do site.

O proprietário da organização não conseguiu criar o repositório interno devido às opções de visibilidade corretas que não estão sendo exibidas no formulário.

A aba de ações do repositório apresentou um 500 nos casos em que os fluxos de trabalho iniciais das ações foram mal configurados.

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.

Serviços de verificação de código de backend não iniciaram de forma confiável após a aplicação de hotpatches.

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.

Alguns registros não foram incluídos na configuração de encaminhamento de registro.

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.

As páginas não foram publicadas ao usar um certificado CA personalizado.

Os subdomínios relacionados aos pacotes não apareceram nas configurações da instrução "Teste de domínio" para o isolamento de subdomínio.

O cabeçalho X-GitHub-Enterprise-Host enviado com webhooks incluiu uma string aleatória, em vez do nome do host da instância do GitHub Enterprise Server que enviou a carga HTTP POST.

Atualizar de 2.22.x para 3.0.x falharia se o GitHub Actions tivesse sido habilitado anteriormente, mas desabilitado antes da atualização.

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

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.

A interpretação de reStructuredText (RST) na interface do usuário da web falharia e, em vez disso, exibiria texto de markup RST.

Notificações de e-mail para alertas de verificação de segredo não foram enviadas para usuários autorizados quando o gráfico de dependências não foi totalmente habilitado.

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

Notebooks de Jupyter com personagens não ASCII podem falhar ao fazer a interpretação.

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.

Quando o modo de manutenção foi habilitado, alguns serviços continuaram a ser listados como "processos ativos" mesmo que esperasse que eles estivessem sendo executados, e não deveriam ter sido listados.

Após a atualização da versão 2.22.x para 3.0.x com o GitHub Actions habilitado, a versão do executor auto-hospedado não foi atualizada e não foi feita nenhuma atualização auto-hospedada.

As criações antigas do GitHub Pages não foram limpas, levando a um maior uso de disco.

O arquivo memcached não estava sendo executado em réplicas ativas.

A atualização falhou ao atualizar as permissões de arquivos quando o GitHub Actions foi habilitado.

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.

O utilitário ghe-saml-mapping-csv de linha de comando apresentou uma mensagem de aviso.

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.

A resolução de conflitos de merge na GUI falharia quando os hooks pre-receive personalizados estão configurados no repositório.

launch-deployer e launch-receiver estavam registrando no nível DEBUG e preenchendo os registros com informações desnecessárias.

O sistema pode perder a faixa do PID do HAProxy.

Quando as ações foram configuradas para usar o armazenamento S3, às vezes os registros poderiam falhar ao carregar.

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.

Ao habilitar o GitHub Actions, a inicialização pode falhar silenciosamente.

Quando o alerta de vulnerabilidade está habilitado, as atualizações para a série 3.0 falhariam.

Trabalhos relacionados com códigos foram colocados na fila, levando a uma acumulação de trabalhos não processados.

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.

Ao fazer um backup, um erro "Aviso: One or more storage objects were not found on the source appliance." estava ocorrendo ao tentar limpar objetos de armazenamento purgáveis.

Ocorreu uma falha no gráfico de dependência ao analisar os arquivos de manifesto de JavaScript yarn.lock, gerando erros HTTP 500 nos registros.

Desabilitar o GitHub Actions às vezes gera falhas.

Hooks pre-receive personalizados não foram autorizados a gravar em /tmp, impedindo que alguns scripts sejam executados corretamente.

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

Um fuso horário definido no GitHub Enterprise 11.10.x ou anterior foi redefinido como fuso horário UTC depois de atualizar para 3.0, o que fez com que os carimbos de data fossem alterados em algumas instâncias.

Clicar em "Publicar seu primeiro pacote" na barra lateral de pacotes no repositório leva a uma página vazia.

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

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

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

Não foi possível usar as chaves para implantação do repositório nos repositórios que contêm objetos LFS.

Na barra lateral de pacotes de um repositório, o ícone Docker era cinza e a dica da ferramenta exibia "This service is deprecated".

Os webhooks configurados com um tipo de conteúdo de application/x-www-form-urlencoded não receberam parâmetros de consulta no texto da solicitação POST.

Os usuários podem descartar uma mensagem obrigatória sem marcar todas as caixas de seleção.

Em alguns casos, após a atualização de uma instância 2.22.X, os ativos de interface web estavam faltando e a página não seria renderizada corretamente.

É possível que se esgote o tempo ao executar ghe-config-apply could time out with Failure waiting for nomad jobs to apply due to 'job' stanza not found.

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: Foi identificada uma vulnerabilidade de controle de acesso imprópria no GitHub Enterprise Server, que permitiu um usuário autenticado com a possibilidade de criar um repositório para divulgar segredos de Ações para o repositório principal da bifurcação. Esta vulnerabilidade existia em razão a uma falha que permitia a referência de um pull request ser atualizado para apontar para um SHA arbitrário ou outro pull request fora do repositório da bifurcação. Ao estabelecer essa referência incorreta em um RP, as restrições que limitam os segredos das ações enviaram um fluxo de trabalho das bifurcações podem ser contornadas. Esta vulnerabilidade afetou as versões 3.0.0, 3.0.rc2 e 3.0.0. c1 do GitHub Enterprise Server e recebeu um CVE-2021-22862. Esta vulnerabilidade foi relatada por meio do programa de Recompensas de Erro do GitHub.

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

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.

Os cabeçalhos HTTP não eram compatíveis com os padrões HTTP RFC em respostas específicas como o status 304 para arquivos.

Em instâncias que hospedem repositórios Python com o recurso de gráfico de dependência, a instância pode tornar-se não responsiva devido ao preenchimento do disco raiz com registros de erro.

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.

No VMWare ESX 6.7 a configuração inicial pode demorar ao criar chaves de host que deixaram a instância inacessível via SSH.

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

A configuração de criação de pacotes foi mostrada na página de configurações de integrantes da organização, embora este recurso ainda não esteja disponível.

Ao habilitar a varredura de segredo na página Segurança e Análise, o diálogo menciona incorretamente repositórios privados.

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 visualizou a mensagem 500 error ao executar operações no git em uma instância configurada com autenticação do LDAP.

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

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.

Corrige os usuários aos quais são apresentados a opção para configurar a Ação do CodeQL da varredura de código, ainda que as ações não tenham sido habilitadas para seu repositório.

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.

O modal usado para exibir uma mensagem obrigatória não continha barra de rolagem vertical, o que significa que as mensagens mais longas não puderam ser visualizadas completamente.

O Redis às vezes pode falhar ao iniciar após uma reinicialização rígida ou falha no aplicativo.

O gráfico de dependências não consegue analisar os arquivos de manifesto setup.py, resultando em erros HTTP 500 nos registros. Isso, aliado à questão da duplicação do registro, gera aumento da utilização do volume da raiz.

As solicitações foram satisfeitas simultaneamente quando vários usuários estão fazendo download do mesmo arquivo, gerando um desempenho melhorado.

ALTO: Uma vulnerabilidade de execução de código remoto foi identificada em GitHub Enterprise Server que poderia ser explorada ao criar um site de GitHub Pages. A configuração controlada pelo usuário dos analisadores usados por GitHub Pages não era suficientemente restrita e possibilitou a execução de comandos na instância de GitHub Enterprise Server. Para explorar essa vulnerabilidade, um invasor precisaria de permissão para criar e construir um site GitHub Pages na instância de GitHub Enterprise Server. Um CVE-2020-10519 foi atribuída a essa vulnerabilidade e foi relatada por meio do Programa de Recompensas do Erro do GitHub.

[GitHub Actions] (https://github.com/features/actions) está disponível em GitHub Enterprise Server 3,0+. Crie, teste e implante seu código a partir de GitHub. Envie revisões de código, gerenciamento de branches e triagem de problemas da maneira que você desejar.

Esta versão inclui várias melhorias da versão beta de GitHub Actions em GitHub Enterprise Server:

• Os administradores corporativos, de organização e repositório podem criar políticas de segurança para acessar GitHub Actions em GitHub.com.
• Os administradores corporativos, de organização e repositórios podem permitir que os repositórios públicos usem executores auto-hospedados.
• Os administradores corporativos, de organização e repositórios agora podem permitir que os fluxos de trabalho sejam executados em pull requests abertos em bifurcações de repositórios privados.
• O evento 'workflow_run' é agora compatível
• Agora, os usuários agora têm a capacidade de desabilitar os fluxos de trabalho e habilitá-los posteriormente.
• Os registros do fluxo de trabalho foram aprimorados para uma melhor experiência do usuário.
• Os usuários agora podem usar imagens privadas em trabalhos e serviços de contêineres.
• Os dias máximos de retenção para [artefatos e registros agora podem ser personalizados](/enterprise-server@3.0/github/configuração-e-gerenciamento-sua-empresa/configuração-o-período de retenção-para-github-ações-artefatos-e-logs-em-sua-conta corporativa).
• A API do grupo do executor agora inclui labels.
• Agora você pode criar ações reutilizáveis usando scripts shell com etapas de execução de composição.
• Segredos criptografados para uma organização permitem que você consolide segredos em repositórios.
• Modelos de fluxo de trabalho para uma organização simplifica e promove as práticas recomendadas e a consistência em toda a sua organização.

GitHub Actions não é atualmente compatível para empresas que usam configurações de cluster.

GitHub Package Registry é um serviço de hospedagem de pacotes, integrado nativamente às APIs, ações e webhooks do GitHub. Crie um fluxo de trabalho de DevOps de ponta a ponta que inclui o 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 que virá em uma versão futura. Observe que o suporte atual do Docker será substituído por uma versão beta do novo GitHub Container Registry na próxima versão. Revise os requisitos mínimos atualizados para sua plataforma antes de ativar GitHub Package Registry.

Ao publicar pacotes no NuGet, os usuários agora podem usar a opção --api-key para passar seu token de autenticação em vez de escrevê-lo em um arquivo. Para obter mais informações, consulte Configurar CLI do dotnet para uso com o GitHub Packages

GitHub Package Registry não é atualmente compatível para empresas que usam configurações de cluster.

O beta de GitHub para dispositivos móveis permite que você faça triagem de notificações e gerencie problemas e pull requests a partir do seu dispositivo. Você pode estar conectado simultaneamente ao celular com uma conta de usuário em GitHub.com e uma conta de usuário em GitHub Enterprise Server.

O beta de GitHub para dispositivos móveis agora está disponível para GitHub Enterprise Server. Efetue o login com os nossos aplicativos Android e iOS para monitorar notificações e gerenciar problemas e pull requests em qualquer lugar. Os administradores podem desabilitar o suporte móvel para a sua Empresa usando o console de gerenciamento ou executando o comando ghe-config app.mobile.enabled false.

[Varredura de segredo beta](https://github. um/recursos/segurança) faz a varredura de repositórios públicos e privados com relação a credenciais comprometidas, encontra segredos, e notifica o provedor do segredo ou administrador no momento em que são autorizados em um repositório.

Os administradores que usam Segurança Avançada GitHub podem [habilitar e configurar](/enterprise-server@3. /admin/configuration/configuring-secret-scanning-for-your-appliance) a varredura de segredo de Segurança Avançada GitHub. Você pode revisar os requisitos mínimos atualizados para sua plataforma antes de habilitar a varredura de segredo de Segurança Avançada GitHub.

A Varredura Avançada de Código de Segurança do GitHub agora está geralmente disponível no GitHub Enterprise Server. As organizações que adquiriram Segurança Avançada podem usar este recurso para fazer testes de segurança de análise estática com seu código e evitar que vulnerabilidades cheguem ao código de produção usando CodeQL, o nosso mecanismo de análise semântica. Para obter mais informações, consulte "Configurar a varredura de código no seu aplicativo"

O sistema de entrega de eventos de webhook foi rearquitetado para rendimentos mais altos, entregas mais rápidas e menor atraso nas mensagens de erro.. Além disso, ele usa menos CPU e memória em GitHub Enterprise Server 3.0+.

Os proprietários da organização e da empresa agora podem ver quando um integrante da equipe foi promovido ou rebaixado de ser um mantenedor de equipe no log de auditoria por meio os novos eventos de log de auditoria team.promote_maintainer e team.demote_maintainer. Para obter mais informações, consulte "Ações auditadas."

Os mantenedores do repositório com os sites de GitHub Pages existentes podem atualizar facilmente o nome padrão anterior do branch.

Additional hardware resources are required to run GitHub Enterprise Server with any of Actions, Packages or Advanced Security enabled. For more information on the minimum required resources for each supported platform, see "Setting up a GitHub Enterprise Server instance."

Agora os administradores podem publicar uma mensagem, que todos os usuários devem aceitar. Isso pode ajudar a integrar novos usuários e supervisionar outras informações e políticas específicas da organização.

Os proprietários da organização agora podem desabilitar a publicação de sites de GitHub Pages dos repositórios na organização. Desabilitar GitHub Pages para a organização impedirá que os integrantes criem novos sites de páginas, mas não irá cancelar a publicação de sites existentes. Para obter mais informações, consulte "Desabilitar a publicação de sites de GitHub Pages para a sua organização."

Um centro de dados deve ser definido explicitamente em todos os nós antes de habilitar uma réplica ativa.

Todo o uso de impressões digitais de SSH foi alterado para usar as impressões digitais de SHA256, pois são usadas com o OpenSSH desde a versão 6.8. Isto se aplica à interface web e também à API em que as impressões digitais são retornadas, como no GraphQL. As impressões digitais seguem o formato OpenSSH.

Os cabeçalhos de assinatura SHA-1 e SHA-256 (dois cabeçalhos) são enviados em webhooks.

A maioria dos serviços em execução em GitHub Enterprise Server 3.0 + estão agora nos contêineres, o que permite que o GitHub itere internamente e envie rapidamente versões de qualidade

O sistema de entrega de eventos webhook foi rearquivado para melhor rendimento, entregas mais rápidas e menor atraso nas mensagens.

Os administradores agora podem configurar e gerenciar o anúncio do banner para todo o site através da API REST. Para obter mais informações, consulte os pontos de extremidade para "Administração do GitHub Enterprise."

Um novo ponto de extremidade da API permite o intercâmbio de um usuário para um token de servidor para um token de servidor com escopo definido para repositórios específicos. Para obter mais informações, consulte "Apps" na documentação da API REST de GitHub

Os administradores da empresa e da organização agora podem definir o nome do branch padrão para novos repositórios. Os administradores das empresas também podem aplicar a sua escolha do nome do branch padrão em todas as organizações ou permitir que as organizações individuais escolham suas próprias.

Os repositórios existentes não são afetados por essas configurações, e seu nome de branch padrão não será alterado.

Esta alteração é uma das muitas mudanças que o GitHub está realizando para ser compatível com projetos e mantenedores que desejam renomear seu branch padrão. Para saber mais sobre as mudanças que estamos criando, consulte github/renaming.

Todos os problemas conhecidos do Candidato 1 e Candidato a Versão 2 foram corrigidos, exceto os listados na seção de Problemas conhecidos abaixo.

Foram corrigidos os problemas com migrações e melhorias para a versão 3.0.0.

O versionamento do Backup de Utilitários agora funciona para versões de candidato de versões.

Gerar um pacote de suporte resultou em um erro nos registros de orquestradores.

Uma grande restauração pode resultar no esgotamento da memória do Redis.

A caixa de seleção para habilitar o GitHub Actions no Console de Gerenciamento agora é visível com qualquer método de autenticação.

GitHub Actions pode ser habilitado se o armazenamento necessário também foi configurado.

O 'ghe-repl-status' pode falhar silenciosamente se a replicação do MSSQL não foi configurada.

O formato de vários arquivos de registro foram alterados, incluindo a adição de um PID para diferentes tipos de registro. Isso não afeta como o Suporte GitHub Enterprise usa pacotes de suporte para solucionar problemas.

Uma solicitação de PATCH para a API de configuração de webhook não apaga mais o segredo do webhook.

Certos tipos de ganchos de hooks pre-receive estavam falhando.

Os Packages do NuGet serviço agora normaliza versões semânticas na publicação. Os clientes do NuGet não conseguem fazer o download da versão semântica inválida (por exemplo: v1.0.0.0.0.). Portanto, espera-se que o serviço do NuGet normalize essas versões (por exemplo: v1.0.0.0.0.0 --> v1.0.0). Qualquer versão original, não normalizada, estará disponível no campo Version. Não são necessárias alterações nas configurações do cliente.

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 rastreados pelo LFS do Git carregados por meio da interface web foram adicionados incorreta e diretamente ao repositório.

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.

Quando o modo de manutenção está habilitado, alguns serviços continuam listados como "processos ativos". Espera-se que os serviços identificados sejam executados durante o modo de manutenção. Se você tiver este problema e não estiver seguro, entre em contato com Suporte do GitHub Enterprise ou Suporte do GitHub Premium.

Quando o GitHub Actions estiver habilitado, use 'ghe-maintenance -u' para cancelar a definição do modo de manutenção.

O registro duplicado para /var/log/messages, /var/log/syslog, e /var/log/user.log geraram um aumento na utilização do volume raiz.

Os usuários podem ignorar uma mensagem obrigatória sem marcar todas as caixas de seleção.

Script de hook de pre-receive não pode escrever arquivos temporários, o que pode gerar falha na execução de script. Os usuários que usam hooks pre-receive devem testar em um ambiente de treinamento para ver se os scripts exigem acesso de gravação.

Não foi possível usar as chaves para implantação do repositório nos repositórios que contêm objetos LFS.

A interpretação do caderno Jupyter na interface do usuário pode falhar se o caderno de anotações incluir caracteres que não são ASCII UTF-8.

O reStructuredText (RST) interpretado na interface do usuário da web pode falhar e, em vez disso, exibir texto de markup RST.

O gráfico de dependências não consegue analisar os arquivos de manifesto setup.py, resultando em erros HTTP 500 nos registros. Isso, aliado à questão da duplicação do registro, gera aumento da utilização do volume da raiz.

Uma condição de corrida pode fazer com que migrações gráficas de dependências apareçam falhadas.

As instâncias com um fuso horário personalizado que foram atualizadas de uma versão anterior do GitHub Enterprise Server podem ter carimbos de tempo incorretos na interface da web.

As criações antigas das páginas não foram limpas, o que pode preencher o disco do usuário (/data/user/).

Ao excluir um branch após o merge de um pull request, será exibida uma mensagem de erro, embora a exclusão do branch tenha êxito.

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.

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

GitHub Enterprise Server 2.19 estará obsoleto a partir de 12 de novembro de 2020. Isso significa que não serão feitas versões de patch, mesmo para questões críticas 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 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.

O serviço era compatível com uma experiência de "Encontrar por Símbolo" na vista de pull request que não era amplamente utilizada.

Os comandos do fluxo de trabalho set-env and add-path de GitHub Actions tornaram-se obsoletos. Para obter mais informações, consulte o changelog.