Enterprise Server 3.0 release notes

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

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.

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.

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

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.

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.

Packages have been updated to the latest security versions. In these updates, Log4j has been updated to version 2.17.1. Note: previous mitigations released in 3.3.1, 3.2.6, 3.1.14, and 3.0.22 are sufficient to address the impact of CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832 in these versions of GitHub Enterprise Server.

Sanitize more secrets in the generated support bundles

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

Running ghe-config-apply could sometimes fail because of permission issues in /data/user/tmp/pages.

The save button in management console was unreachable by scrolling in lower resolution browsers.

IOPS and Storage Traffic monitoring graphs were not updating after collectd version upgrade.

Some webhook related jobs could generated large amount of logs.

Critical: A remote code execution vulnerability in the Log4j library, identified as CVE-2021-44228, affected all versions of GitHub Enterprise Server prior to 3.3.1. The Log4j library is used in an open source service running on the GitHub Enterprise Server instance. This vulnerability was fixed in GitHub Enterprise Server versions 3.0.22, 3.1.14, 3.2.6, and 3.3.1. For more information, please see this post on the GitHub Blog.

December 17, 2021 update: The fixes in place for this release also mitigate CVE-2021-45046, which was published after this release. No additional upgrade for GitHub Enterprise Server is required to mitigate both CVE-2021-44228 and CVE-2021-45046.

Support bundles could include sensitive files if they met a specific set of conditions.

A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed more permissions to be granted during a GitHub App's user-authorization web flow than was displayed to the user during approval. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.3 and was fixed in versions 3.2.5, 3.1.13, 3.0.21. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2021-41598.

A remote code execution vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.3 and was fixed in versions 3.0.21, 3.1.13, 3.2.5. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2021-41599. Updated February 17, 2022.

Running ghe-config-apply could sometimes fail because of permission issues in /data/user/tmp/pages.

A misconfiguration in the Management Console caused scheduling errors.

Docker would hold log files open after a log rotation.

GraphQL requests did not set the GITHUB_USER_IP variable in pre-receive hook environments.

Clarifies explanation of Actions path-style in documentation.

Updates support contact URLs to use the current support site, support.github.com.

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

Pre-receive hooks would fail due to undefined PATH.

Running ghe-repl-setup would return an error: cannot create directory /data/user/elasticsearch: File exists if the instance had previously been configured as a replica.

In large cluster environments, the authentication backend could be unavailable on a subset of frontend nodes.

Some critical services may not have been available on backend nodes in GHES Cluster.

An additional outer layer of gzip compression when creating a cluster support bundle with ghe-cluster-suport-bundle is now turned off by default. This outer compression can optionally be applied with the ghe-cluster-suport-bundle -c command line option.

We have added extra text to the admin console to remind users about the mobile apps' data collection for experience improvement purposes.

The GitHub Connect data connection record now includes a list of enabled GitHub Connect features. [Updated 2021-12-09]

A path traversal vulnerability was identified in GitHub Pages builds on GitHub Enterprise Server that could allow an attacker to read system files. To exploit this vulnerability, an attacker needed 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.3, and was fixed in versions 3.0.19, 3.1.11, and 3.2.3. This vulnerability was reported through the GitHub Bug Bounty program and has been assigned CVE-2021-22870.

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

Some Git operations failed after upgrading a GitHub Enterprise Server 3.x cluster because of the HAProxy configuration.

Unicorn worker counts might have been set incorrectly in clustering mode.

Resqued worker counts might have been set incorrectly in clustering mode.

If Ubuntu's Uncomplicated Firewall (UFW) status was inactive, a client could not clearly see it in the logs.

Some pages and Git-related background jobs might not run in cluster mode with certain cluster configurations.

The enterprise audit log page would not display audit events for varredura secreta.

Users were not warned about potentially dangerous bidirectional unicode characters when viewing files. For more information, see "Warning about bidirectional Unicode text" in GitHub Blog.

Hookshot Go sent distribution type metrics that Collectd could not handle, which caused a ballooning of parsing errors.

Public repositories displayed unexpected results from varredura secreta with a type of Unknown Token.

Several known weak SSH public keys have been added to the deny list and can no longer be registered. In addition, versions of GitKraken known to generate weak SSH keys (7.6.x, 7.7.x and 8.0.0) have been blocked from registering new public keys.

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

Several parts of the application were unusable for users who are owners of many organizations.

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.

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.

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.

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)

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. The fix also requires updating backup-utils to 3.2.0 or higher. [updated: 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 usavam uma subshell retornariam o erro: No such file or directory.

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.

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.

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.

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.

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.

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.

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

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

Executar git nw-gc --pristine geraria um erro.

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.

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 uma quantidade relativa para o bootstrap_expect cônsul e nômago permitindo que um cluster seja inicializado mesmo que alguns nós estejam fora de serviço.

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

São necessários recursos adicionais de hardware para executar GitHub Enterprise Server com qualquer uma das Ações, Pacotes ou Segurança Avançada habilitadas. Para obter mais informações sobre os recursos mínimos necessários para cada plataforma compatível, consulte "Configurar uma instância de GitHub Enterprise Server."

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 GitHub Enterprise Support.

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.

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