Enterprise Server 3.6 release notes

In the Management Console's monitor dashboard, the Cached Requests and Served Requests graphs, which are retrieved by the git fetch catching command, did not display metrics for the instance.

After a site administrator exempted the @github-actions[bot] user from rate limiting by using the ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]" command, running ghe-config-check caused a Validation is-valid-characterset failed warning to appear.

GitHub Actions (actions) and Microsoft SQL (mssql) did not appear in the list of processes within the instances monitor dashboard.

After an administrator used the /setup/api/start REST API endpoint to upload a license, the configuration run failed with a Connection refused error during the migrations phase.

In some cases, on an instance with a GitHub Advanced Security license and secret scanning enabled, users may have seen a discrepancy between the number of alerts displayed on a repositorys "Security" tab and in the sidebar for the "Security" tab.

On an instance in a cluster configuration, when a site administrator set maintenance mode using ghe-maintenance -s, a Permission denied error appeared when the utility tried to access /data/user/common/cluster.conf.

On an instance in a high availability configuration, if an administrator tore down replication from a replica node using ghe-repl-teardown immediately after running ghe-repl-setup, but before ghe-repl-start, an error indicated that the script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown now displays an informational alert and continues the teardown.

During configuration of high availability, if a site administrator interrupted the ghe-repl-start utility, the utility erroneously reported that replication was configured, and the instance would not perform expected clean-up operations.

Responses from the /repositories REST API endpoint erroneously included deleted repositories.

When a site administrator used ghe-migrator to migrate data to GitHub Enterprise Server, in some cases, nested team relationships would not persist after teams were imported.

If a repository contained a CODEOWNERS file with check annotations, pull requests "Files changed" tab returned a 500 error and displayed "Oops, something went wrong" in the "Unchanged files with check annotations" section.

After upgrading an instance with a GitHub Advanced Security license to GitHub Enterprise Server 3.6 or 3.7, creating a repository or viewing the security settings page for an organization or repository could result in a 500 error due to a GitHub Advanced Security backfill job not completing before the upgrade started.

On an instance with GitHub Actions enabled, if a user manually triggered a workflow using the REST API but did not specify values for optional booleans, the API failed to validate the request and returned a 422 error.

The CSV reports for all users and all active users, available from the site admin dashboard, did not consider recent access using SSH or personal access tokens.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, users would not see issues in private and internal repositories in search results for GitHub.com.

GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids, and git.hooks.runtime.

On an instance with a GitHub Advanced Security license, if code scanning had been used while running GitHub Enterprise Server 3.4 or earlier, a subsequent upgrade from 3.5 to 3.6 or 3.7 could fail when attempting to add a unique index to a database table.

After an enterprise owner enables Dependabot updates, the instance creates the initial set of updates faster.

On an instance in a cluster configuration, when a site administrator sets maintenance mode on a single cluster node using ghe-maintenance -s, the utility warns the administrator to use ghe-cluster-maintenance -s to set maintenance mode on all of the clusters nodes. For more information, see "Habilitar e programar o modo de manutenção."

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "Configurando um servidor proxy Web de saída."

To avoid intermittent issues with the success of Git operations on an instance with multiple nodes, GitHub Enterprise Server checks the status of the MySQL container before attempting a SQL query. The timeout duration has also been reduced.

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "Utilitários de linha de comando."

"ALTA: foi identificada uma vulnerabilidade de percurso de caminho no GitHub Enterprise Server que permitia a execução remota de códigos ao criar um site do GitHub Pages. Para explorar esta vulnerabilidade, um invasor precisaria de permissão para criar e compilar um site GitHub Pages na instância do GitHub Enterprise Server. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-23760.

Ao exibir uma lista de sessões abertas para os dispositivos conectados a uma conta de usuário, a interface do usuário da Web do GitHub Enterprise Server pode exibir um local incorreto.

No caso raro em que os fragmentos primários do Elasticsearch estavam localizados em um nó de réplica, o comando ghe-repl-stop falhava com ERROR: Running migrations.

A página de configurações para discussões em uma organização retornou um erro 500 depois que um repositório pertencente à organização foi excluído.

ALTA: atualização do Git para incluir as correções de 2.39.2, que abordam CVE-2023-22490 e CVE-2023-23946.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Ao usar uma URL de ponto de extremidade VPC como uma URL do AWS S3 para pacotes do GitHub, ocorria uma falha na publicação e instalação dos pacotes.

Em uma instância com uma licença do GitHub Advanced Security, se a verificação de código tiver sido usada durante a execução do GitHub Enterprise Server 3.4 ou anterior, uma atualização subsequente de 3.5 para 3.6 ou 3.7 poderia falhar ao tentar adicionar um índice exclusivo a uma tabela de banco de dados.

MÉDIA: uma vulnerabilidade de injeção de código foi identificada no GitHub Enterprise Server que permitiu definir variáveis de ambiente arbitrárias de um só valor de variável de ambiente no GitHub Actions quando um executor baseado no Windows é usado devido à limpeza inadequada de bytes nulos. Para explorar essa vulnerabilidade, um invasor precisava ter uma permissão existente para controlar o valor das variáveis de ambiente para uso com o GitHub Actions. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-22381.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Depois que um administrador do site ajustava a data limite para permitir conexões SSH com chaves RSA usando ghe-config app.gitauth.rsa-sha1, a instância ainda não permitia conexões com chaves RSA se a tentativa de conexão fosse assinada pela função de hash SHA-1.

Durante a fase de validação de uma execução de configuração, um No such object error pode ter ocorrido nos serviços Notebook e Viewscreen.

Ao habilitar o gerenciamento automático de certificados TLS com Let's Encrypt, o processo pode falhar com o erro The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates.

Em alguns casos, os usuários não podiam converter problemas existentes em discussões. Se um problema travar durante a conversão em uma discussão, os proprietários da empresa podem examinar a seção "Problemas conhecidos" abaixo para obter mais informações.

Quando ocorre um tempo limite durante a geração do diff, como quando um commit exibe um erro em que a geração do diff está levando muito tempo, o evento do webhook push fornecerá informações diff vazias. Anteriormente, o evento de webhook push falhava ao ser entregue.

ALTA: Atualização do Git para incluir as correções de 2.39.1, que abordam CVE-2022-41903 e CVE-2022-23521.

Limpe segredos adicionais em pacotes de suporte e no log de configuração.

As dependências da ação do CodeQL foram atualizadas para as versões de segurança mais recentes.

Os pacotes foram atualizados para as versões de segurança mais recentes.

As métricas Active workers e Queued requests dos serviços de contêiner github (renomeadas com base nos metadados), gitauth e unicorn não eram lidas corretamente nos itens coletados e exibidos no Console de Gerenciamento.

Os emails de alerta do Dependabot seriam enviados para repositórios desabilitados.

As migrações de dados podem falhar quando a tabela de banco de dados subjacente contém apenas um único registro.

Ao exibir uma comparação de solicitações de pull para um arquivo grande com muitas linhas entre as alterações, não foi possível expandir o modo de exibição para exibir todas as alterações.

O git-janitorcomando não pôde corrigir arquivos desatualizados multi-pack-index.lock, resultando na falha na manutenção do repositório.

A variável de ambiente GITHUB_REF_PROTECTED e os contextos github.ref_protected foram definidos incorretamente como false quando as proteções de branch existiam.

As métricas launch.* descartadas não podem ser analisadas por statsd, pois os erros de statsd resultantes fizeram com que os logs coletados aumentassem rapidamente de tamanho.

Ao atualizar padrões personalizados, o estado do padrão foi definido imediatamente como publicado.

Melhorou a confiabilidade do serviço de atualizações em tempo real (Alive) para torná-lo mais resiliente contra problemas de rede com o Redis.

Os comandos ghe-support-bundle e ghe-cluster-support-bundle foram atualizados para incluir o sinalizador -p/--period para gerar um pacote de suporte com restrição de tempo. A duração pode ser especificada em dias e horas, por exemplo: -p '2 hours', -p '1 day', -p '2 days 5 hours'.

Ao atualizar uma instância com uma nova partição raiz, a execução do comando ghe-upgrade com a opção -t/--target garante que a verificação de simulação do tamanho mínimo de armazenamento em disco seja executada na partição de destino.

O desempenho das execuções de configuração iniciadas com ghe-config-apply foi aprimorado.

Ao exportar dados da conta, fazer backup de um repositório ou executar uma migração, o link para um arquivo morto do repositório agora expira após uma hora. Anteriormente, o link de arquivo morto expirava após cinco minutos.

ALTO: foi identificada uma vulnerabilidade de transversalidade de caminho no GitHub Enterprise Server que permitia a execução remota de códigos ao criar um site do GitHub Pages. A fim de explorar essa vulnerabilidade, um invasor precisaria de permissão para criar e compilar um site do GitHub Pages na instância. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-46256.

ALTO: uma vulnerabilidade de autorização incorreta permitia que um token de usuário para servidor com escopo definido fosse escalado para um acesso de administrador completo a um repositório. Um invasor precisaria de uma conta com acesso de administrador para instalar um Aplicativo GitHub mal-intencionado. Essa vulnerabilidade afetava todas as versões do GitHub Enterprise Server anteriores à 3.7.0. Ela foi relatada pelo Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23741.

MÉDIA: uma vulnerabilidade de divulgação de informações confidenciais foi identificada no GitHub Enterprise Server que permitia que repositórios privados fossem adicionados a um grupo de executores do GitHub Actions por meio da API por um usuário que não tinha acesso a esses repositórios, resultando na exibição dos nomes dos repositórios na interface do usuário. Para explorar essa vulnerabilidade, um invasor precisava ter acesso à instância do GHES, permissões para modificar os grupos de executores do GitHub Actions e adivinhar com sucesso a ID oculta dos repositórios privados. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-46257.

Uma condição de corrida bloqueava as atualizações para o GitHub Enterprise Server 3.6 ou posterior até que um administrador do site repetisse a atualização.

Os administradores do site não conseguiam gerenciar as configurações dos produtos de segurança para os repositórios desbloqueados.

Quando um administrador de site executava o comando ghe-repl-status em uma réplica de cache por meio do shell administrativo (SSH), o comando relatava incorretamente informações gerais de status de replicação de cluster do Git e do Alambic como se pertencesse somente à replicação de cache.

Quando um administrador de site executava o comando ghe-repl-sync-ca-certificates de um nó primário de instâncias por meio do shell administrativo (SSH), o comando somente replicava certificados de AC do nó primário de instâncias para um único nó de réplica. O comando não replicava os certificados em todos os nós de réplica disponíveis.

Ao usar o armazenamento em cache do repositório com uma instância em uma configuração de alta disponibilidade, se um cliente Git usasse SSH em vez de HTTPS para uma URL remota de repositório, o Git LFS buscava objetos do nó primário da instância em vez de no nó de réplica do cache apropriado.

A instalação do GitHub Enterprise Server no hipervisor do VMware ESXi falhava devido à geração de um arquivo OVA com um valor de capacidade inválido.

Quando os usuários executavam uma operação usando a API, o GitHub Enterprise Server impunha cotas de tamanho de repositório mesmo quando elas estavam desabilitadas globalmente.

Se um usuário carregasse mais de um arquivo ao criar um Gist, não conseguia excluir nenhum arquivo carregado após o primeiro.

Em alguns casos, pesquisas por meio da API retornavam um erro 500.

Em alguns casos, ao navegar em repositórios na interface da Web, um banner incorreto indicava que um repositório não continha um caminho indefinido específico no branch atual.

O evento de webhook member não incluía os valores de campo from e to para o campo permission como parte do campo changes.

Adicionar um colaborador a um fork de propriedade do usuário em um repositório privado de propriedade da organização com triagem, manutenção ou acesso personalizado resultava em um erro 500.

Em alguns casos, a página para configurar a verificação de código informava erroneamente que o GitHub Actions não estava configurado para a instância.

Depois que a conta de um usuário era excluída da instância, os anexos de imagem carregados por ele nos comentários não ficavam mais visíveis na interface da Web.

Uma mensagem de nível de depuração aparecia em um log do sistema, podendo consumir espaço rapidamente no volume de armazenamento raiz da instância.

Para evitar a falha na verificação de domínio devido ao limite de 63 caracteres imposto pelos provedores DNS para registros DNS, o registro TXT gerado pelo GitHub para verificar a propriedade do domínio agora está limitado a 63 caracteres.

Depois que um proprietário da empresa habilita os alertas do Dependabot, o GitHub Enterprise Server enfileira a sincronização de dados de consultoria para garantir atualizações por hora de GitHub.com.

A lista de repositórios acessados recentemente de um usuário não inclui mais os repositórios excluídos.

Para os participantes na versão beta privada do SCIM do GitHub Enterprise Server, agora há suporte para mapeamentos personalizados dos atributos de usuário SAML. Os mapeamentos personalizados permitem o uso de um valor diferente de NameID como a declaração de identificação exclusiva durante a autenticação SAML. Para obter mais informações, confira "Como configurar o provisionamento de usuários com o SCIM na empresa". [Atualizado em 27-02-2023]

MÉDIO: o CommonMarker foi atualizado para resolver um cenário em que solicitações paralelas para a API REST de Markdown podiam resultar em um esgotamento de recursos não associados. Essa vulnerabilidade foi designada CVE-2022-39209.

MÉDIO: os tokens de usuário para servidor com escopo dos Aplicativos do GitHub podem ignorar verificações de autorização em solicitações de API do GraphQL ao acessar recursos não repositórios. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23739.

MÉDIO: os links de visualização de solicitação de pull não limparam corretamente as URLs, permitindo que um usuário mal-intencionado insira links perigosos na interface do usuário da Web de instâncias. Esta vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub.

MÉDIO: uma vulnerabilidade de autorização incorreta foi identificada no GitHub Enterprise Server que permitiu que um token no escopo do repositório com acesso de leitura/gravação modificasse arquivos de fluxo de trabalho do GitHub Actions sem um escopo de fluxo de trabalho. O "Conteúdo do repositório" deve impor o escopo do fluxo de trabalho. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bug do GitHub e foi designada CVE-2022-46258.

Se uma dependência do GitHub Actions usar uma versão SHA fixada, o Dependabot não a marcará mais como vulnerável.

A definição do modo de manutenção com uma lista de exceção de IP não tinha persistência nas atualizações.

As compilações do GitHub Pages podiam expirar em instâncias na AWS configuradas para alta disponibilidade.

Os detalhes de status da replicação de objetos do Git LFS nos nós de réplica do cache do repositório não eram visíveis na saída ghe-repl-status desses nós.

Após a configuração do Dependabot e dos emails de resumo de alerta, a instância enviava emails de resumo para usuários suspensos.

O carimbo de data/hora do log de auditoria para eventos de alerta do Dependabot retornava a data de criação do alerta em vez do carimbo de data/hora quando um usuário realizava uma ação no alerta.

Ao usar a ação CodeQL, as anotações de execução incluem um erro espúrio HttpError: Upload not found.

Ao acessar recursos JavaScript de uma instância atrás de um proxy, o navegador exibia erros de CORS (compartilhamento de recursos entre origens).

Quando um usuário nomeava uma verificação de status com espaços à esquerda ou à direita, a instância criava uma verificação duplicada caso houvesse outra verificação com o mesmo nome e nenhum espaço à esquerda ou à direita.

Quando um usuário configurava um gancho de pré-recebimento para diversos repositórios, a página Ganchos das instâncias nem sempre exibiam o status correto para ele.

Em alguns casos, uma instância podia substituir um repositório ativo por um excluído.

Os objetos do Git LFS em um repositório com uma política de replicação de cache não eram copiados para réplicas de cache quando o número total de objetos no repositório excedia 5.000.

Depois de executar migrações com relação ao GitHub Enterprise Importer em uma instância configurada para alta disponibilidade, a replicação dos ativos de armazenamento de migração não era atualizada.

Os processos zumbis não se acumulam mais no contêiner gitrpcd.

Se um administrador de site ainda não tiver configurado o GitHub Actions para a instância, a IU para configurar a verificação de código solicitará que o usuário o configure.

ALTO: dependências atualizadas do Console de Gerenciamento para as versões de patch mais recentes, que abordam vulnerabilidades de segurança, incluindo CVE-2022-30123 e CVE-2022-29181.

ALTO: verificações foram adicionadas para resolver uma vulnerabilidade de chave de cache imprópria que permitia que um agente não autorizado acessasse arquivos de um repositório privado por meio de um repositório público. Essa vulnerabilidade recebeu a designação CVE-2022-23738.

MÉDIO: o CommonMarker foi atualizado para resolver um cenário em que solicitações paralelas para a API REST de Markdown podiam resultar em um esgotamento de recursos não associados. Essa vulnerabilidade foi designada CVE-2022-39209.

MÉDIO: o Redis foi atualizado para a 5.0.14 a fim de abordar CVE-2021-32672 e CVE-2021-32762.

MÉDIO: os executores do GitHub Actions foram atualizados para corrigir um bug que permitia que variáveis de ambiente em trabalhos do GitHub Actions escapassem do contexto da variável e modificassem a invocação de comandos docker diretamente. Para saber mais, confira a consultoria de segurança do Actions Runner.

MÉDIO: foi identificada no GitHub Enterprise Server uma vulnerabilidade de gerenciamento de privilégios inadequados que permitia que usuários com privilégios inadequados criassem ou excluíssem páginas por meio da API. Para explorar essa vulnerabilidade, um invasor precisaria ser adicionado ao repositório de uma organização com permissões de gravação. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23737.

BAIXO: devido a uma vulnerabilidade do CSRF, uma solicitação GET para o ponto de extremidade site/toggle_site_admin_and_employee_status da instância podia alternar o status de administrador do site de um usuário sem fornecer notificação.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Depois que um administrador de site fazia uma alteração que disparava uma execução de configuração, como desabilitar o GitHub Actions, a validação dos serviços falhava algumas vezes com a mensagem WARNING: Validation encountered a problem.

Depois que um administrador de site instalava um hotpatch com alterações para ativos da interface da Web, como arquivos JavaScript ou imagens, a instância não fornecia os novos ativos.

Quando um usuário acessava um repositório renomeado usando o Git, o nome do host na saída do Git indicava incorretamente GitHub.com em vez do nome do host da instância.

Em instâncias que usam autenticação e sincronização LDAP, a sincronização falharia e imprimiria undefined method ord for nil:NilClass no ldap-sync.log.

Quando um usuário visitava links para exibir o histórico ou sugerir uma melhoria no Banco de Dados de Consultoria do GitHub, as URLs eram incorretas, resultando em um 404 erro.

Ativos excluídos e agendados para limpeza em um repositório, como arquivos LFS, demoravam muito para serem limpos.

Em instâncias configuradas para alta disponibilidade, ghe-repl-status relatava incorretamente que a replicação estava atrasada para repositórios que os usuários haviam excluído anteriormente.

Se um usuário instalava um Aplicativo GitHub para uma conta de usuário e a convertia em uma organização, o aplicativo não recebia permissões para a organização.

Os alertas de verificação de segredo ausentes na instância com uma licença do GitHub Advanced Security que não era atualizada diretamente para o GitHub Enterprise Server 3.4 agora estão visíveis na interface da Web e por meio da API REST.

Em alguns casos, em uma instância com uma licença GitHub Advanced Security, alguns tokens detectados pela verificação secreta foram relatados como "tokens desconhecidos".

Para garantir que os administradores de site possam concluir uma atualização com êxito, a instância agora executará uma verificação de simulação a fim de garantir que a máquina virtual atenda aos requisitos mínimos de hardware. A verificação também confere a integridade do Elasticsearch. É possível examinar os requisitos atuais de CPU, memória e armazenamento do GitHub Enterprise Server na seção "Requisitos mínimos" de cada artigo em "Configurar uma instância do GitHub Enterprise Server".

Os arquivos do repositório para migrações agora incluem um campo is_archived.

ALTO: um Aplicativo do GitHub poderia usar um token de usuário para servidor com escopo definido a fim de ignorar a lógica de autorização do usuário e escalonar privilégios.

BAIXO: conceder a um usuário a capacidade de ignorar as proteções de branch não permite mais que ele ignore o requisito de verificação de assinatura.

Os pacotes foram atualizados para as versões de segurança mais recentes.

Em alguns casos, o collectd registrava erros excessivos relacionados a métricas em /var/log/collectd.log.

Ao configurar o nome de domínio externo de um nó de réplica do cache do repositório usando ghe-repl-node --cache-domain, o comando retornava um erro que impedia que o cache do Git LFS fosse habilitado.

A instalação de um certificado TLS falhava quando a cadeia de caracteres de assunto do certificado incluía caracteres UTF-8.

As execuções de configuração podiam falhar quando retry-limit ou retry-sleep-duration eram definidos manualmente por um administrador usando ghe-config.

A opção para habilitar a criptografia TLS para conexões SMTP de entrada com relação a uma instância estava ausente do console de gerenciamento.

Em alguns casos, o painel do monitor do console de gerenciamento não era carregado corretamente.

Foi removido um link não funcional para exportar gráficos do monitor do console de gerenciamento como uma imagem PNG.

O comando ghe-find-insecure-git-operations não retornava todas as operações não seguras do Git após cada invocação.

Ao enviar um pacote de suporte para o GitHub Enterprise Support usando ghe-support-upload, a opção -t não associava com êxito o pacote carregado ao tíquete especificado.

Um link de redirecionamento para as configurações de segurança da conta corporativa da instância podia resultar em uma exibição incorreta.

Em casos raros, uma atualização do GitHub Enterprise Server 3.3 para 3.4 modificava incorretamente como os dados eram armazenados, o que resultava em falhas durante atualizações futuras. Ao atualizar diretamente da 3.3 para essa versão, a falha não ocorrerá.

Ao usar uma URL de ponto de extremidade VPC como uma URL do AWS S3 para pacotes do GitHub, ocorria uma falha na publicação e instalação dos pacotes.

Os clones ou buscas do Git por SSH podiam sofrer corrupção de dados em transferências com tamanho superior a 1 GB.

Depois que um usuário excluía ou restaurava pacotes da interface da Web, as contagens de pacotes podiam ser renderizadas incorretamente.

Após a configuração bem-sucedida do Dependabot e dos emails de resumo de alerta, a instância não enviava emails de resumo.

Os fluxos de trabalho do GitHub Actions desabilitados manualmente em um repositório eram reabilitados quando o repositório recebia um push contendo mais de 2.048 confirmações ou quando o branch padrão do repositório era alterado.

Ao exibir a diferença de uma solicitação de pull para um arquivo grande com muitas linhas entre as alterações, não era possível expandir a exibição de todas as alterações.

Quando as proteções de branches eram habilitadas, a variável de ambiente GITHUB_REF_PROTECTED e os contextos github.ref_protected das execuções de fluxo de trabalho do GitHub Actions eram definidos incorretamente como false.

Os repositórios de pacotes exibiam erroneamente uma seção "Usado por".

Após desbloquear um repositório para acesso temporário, o administrador do site não conseguiu gerenciar as configurações dos produtos de segurança no repositório.

Chaves SSH administrativas duplicadas podiam aparecer tanto no Console de Gerenciamento quanto no arquivo /home/admin/.ssh/authorized_keys.

A página de administração do site para usuários individuais na funcionalidade contida http(s)://HOSTNAME/stafftools/users/USERNAME/admin não se destina ao GitHub Enterprise Server.

Em alguns casos, a execução de ghe-cluster-config-apply podia replicar uma configuração vazia nos nós existentes de um cluster.

Em alguns casos, as execuções de configuração iniciadas com ghe-config-apply não eram concluídas ou retornavam um erro Container count mismatch.

Depois de atualizar um certificado TLS autoassinado em uma instância de servidor do GitHub Enterprise, os elementos da interface do usuário em algumas páginas da interface da Web não apareciam.

Em alguns casos, as tarefas em segundo plano podem parar devido a uma biblioteca que foi usada simultaneamente, apesar de não ser thread-safe.

A barra de administração do site na parte superior da interface da Web continha um link quebrado para o SHA para a versão do aplicativo em execução no momento.

Os proprietários da organização não conseguiram definir o nível de acesso necessário para criar discussões.

Os usuários das discussões foram direcionados incorretamente para as diretrizes da comunidade do GitHub.com.

Em alguns casos, os usuários foram instruídos incorretamente a verificar seus emails antes de criar uma discussão.

Alertas da verificação de segredo para clientes do GitHub Advanced Security estavam ausentes na interface do usuário da Web e na API REST se um administrador do site não atualizasse diretamente para o GitHub Enterprise Server 3.4. Os alertas agora estão visíveis.

Como resultado da sanitização de log paralelizada, a geração de pacotes de suporte ficou mais rápida. Para saber mais sobre pacotes de suporte, confira "Fornecer dados para o GitHub Support".

As APIs que contêm a rota organization ou org agora aceitam o slug ou a ID da organização. Anteriormente, as APIs aceitavam apenas slugs, o que fazia com que os cabeçalhos Link dos pontos de extremidade do GitHub Advanced Security ficassem inacessíveis. Para obter mais informações, confira "Organizações" na documentação da API REST.

O log de auditoria da empresa agora inclui mais eventos gerados pelo usuário, como project.create. A API REST também retorna eventos adicionais gerados pelo usuário, como repo.create. Para obter mais informações, confira "Como acessar o log de auditoria da sua empresa" e "Como usar a API do log de auditoria para sua empresa."

Em alguns casos, as réplicas de cache podem rejeitar algumas operações do Git em repositórios atualizados recentemente. Para saber mais sobre o cache de repositório, confira "Sobre o cache do repositório".

Agora você pode configurar o banner de anúncio global como dispensável usando a API REST. Para obter mais informações, confira "Personalizar mensagens de usuário para sua empresa".

O cache de repositório está disponível para o público geral. O cache de repositório aumenta o desempenho de leitura do Git para desenvolvedores distribuídos, fornecendo a localidade de dados e a conveniência da replicação geográfica sem impacto nos fluxos de trabalho por push. Com a versão de disponibilidade geral, o GitHub Enterprise Server armazena em cache os dados do Git e do Git LFS. Para obter mais informações, confira "Sobre o cache do repositório".

Os administradores do site podem configurar uma data de corte para permitir operações do Git por SSH que usam uma chave RSA e são assinadas pela função de hash SHA-1. Por padrão, essas conexões falharão para chaves RSA adicionadas às contas de usuário após a meia-noite UTC da data de corte, 1º de agosto de 2022. Para obter mais informações, confira Desativações. [Atualizado em 31-01-2023]

Opcionalmente, o GitHub Enterprise Server permite o anúncio de uma chave de host Ed25519. Para obter mais informações, confira "Como configurar chaves de host para sua instância".

Você pode exigir a criptografia TLS para conexões SMTP de entrada para sua instância. Para obter mais informações, confira "Como configurar o email para notificações".

• Observação: esse recurso não está disponível no GitHub Enterprise Server 3.6.0 e 3.6.1. O recurso está disponível na versão 3.6.2. [Atualizado em: 22/09/2022]

Você pode transmitir log de auditoria e eventos do Git para sua instância no Amazon S3, Armazenamento de Blobs do Azure, Hubs de Eventos do Azure, Google Cloud Storage ou Splunk. O streaming de log de auditoria está em versão beta pública e sujeito a alterações. Para obter mais informações, confira "Streaming do log de auditoria para sua empresa".

As Estatísticas do servidor agora está disponível ao público em geral. As estatísticas do servidor coletam dados de uso agregados de sua instância do GitHub Enterprise Server, que você pode usar para antecipar melhor as necessidades de sua organização, entender como sua equipe trabalha e mostrar o valor que você obtém do GitHub Enterprise Server. Para obter mais informações, confira "Sobre Estatísticas do Servidor".

Os proprietários corporativos podem ingressar em organizações na instância como membro ou proprietário na página Organizações da conta corporativa. Para obter mais informações, confira "Como gerenciar sua função em uma organização pertencente à sua empresa".

Os proprietários corporativos podem permitir que os usuários descartem o banner de anúncio global configurado. Para obter mais informações, confira "Como personalizar mensagens de usuário para sua empresa".

Os usuários em uma instância com uma licença do GitHub Advanced Security podem optar por receber um evento de webhook que é acionado quando um proprietário da organização ou administrador de repositório ativa ou desativa um recurso de análise ou segurança de código. Para saber mais, confira a seguinte documentação.

• "Eventos e cargas de webhook" na documentação do webhook
• "Como gerenciar as configurações de segurança e análise da sua organização"
• "Como gerenciar os recursos de segurança e de análise do seu repositório"

Os usuários em uma instância com uma licença do GitHub Advanced Security podem opcionalmente adicionar um comentário ao dispensar um alerta de verificação de código na interface do usuário da Web ou por meio da API REST. Os comentários de dispensa aparecem na linha do tempo do evento. Os usuários também podem adicionar ou recuperar um comentário de dispensa por meio da API REST. Para obter mais informações, confira "Triagem de alertas de verificação de código em solicitações de pull" e "Verificação de Código" na documentação da API REST.

Em instâncias com uma licença do GitHub Advanced Security, a verificação de segredo evita o vazamento de segredos no editor da web. Para obter mais informações, confira "Como proteger os pushes com a verificação de segredos".

Proprietários e usuários corporativos em uma instância com uma licença do GitHub Advanced Security podem visualizar alertas de verificação de segredo e ignorar a proteção por push da verificação de segredo nos logs de auditoria da empresa e da organização e por meio da API REST. Para saber mais, confira a seguinte documentação.

• "Como proteger pushes com a verificação de segredos"
• "Auditar eventos de log para sua empresa"
• "Como revisar o log de auditoria da sua organização"
• "Verificação de segredo" na documentação da API REST

Os proprietários corporativos em uma instância com uma licença do GitHub Advanced Security podem realizar simulações de padrões de verificação de segredo personalizados para a empresa, e todos os usuários podem realizar simulações ao editar um padrão. As simulações permitem que você entenda o impacto de um padrão em toda a instância e aprimore o padrão antes da publicação e geração de alertas. Para obter mais informações, confira "Como definir padrões personalizados para a verificação de segredos".

Os usuários em uma instância com uma licença do GitHub Advanced Security podem usar os parâmetros sort e direction na API REST ao recuperar alertas de verificação de segredo e classificar com base nos campos created ou updated do alerta. Os novos parâmetros estão disponíveis para toda a instância ou para organizações ou repositórios individuais. Para saber mais, confira a seguinte documentação.

• "Listar alertas de verificação de segredo para uma empresa"
• "Listar alertas de verificação de segredo para uma organização"
• "Listar alertas de verificação de segredo para um repositório"
• "Verificação de segredo" na documentação da API REST

O conteúdo do repositório github/codeql-go foi movido para o repositório github/codeql, para ficar ao lado de bibliotecas semelhantes para todas as outras linguagens de programação suportadas pelo CodeQL. Agora é possível encontrar em um novo local as consultas, bibliotecas e o extrator CodeQL de código aberto para analisar bases de código escritas na linguagem de programação Go com as ferramentas de análise de código CodeQL do GitHub. Para obter mais informações, incluindo diretrizes sobre como migrar seus fluxos de trabalho existentes, confira github/codeql-go#741.

Proprietários corporativos em instâncias com uma licença do GitHub Advanced Security podem ter uma visão geral dos alertas do Dependabot para toda a instância, incluindo uma visão centrada no repositório dos riscos de segurança do aplicativo e uma visão centrada em alertas de todas as verificações de segredo e alertas do Dependabot. As visualizações estão em versão beta e estão sujeitas a alterações, e as visualizações centradas em alertas para verificação de código estão planejadas para uma versão futura do GitHub Enterprise Server. Para obter mais informações, confira "Como exibir a visão geral de segurança".

Os usuários podem selecionar vários alertas do Dependabot e, em seguida, dispensar ou reabrir ou dispensar os alertas. Por exemplo, na guia Alertas fechados, você pode selecionar vários alertas que foram dispensados anteriormente e reabri-los todos de uma vez. Para saber mais, confira "Sobre os alertas do Dependabot".

• Observação: esse recurso não está disponível no GitHub Enterprise Server 3.6.0. Esse recurso está disponível no GitHub Enterprise Server 3.7.0 e posteriores. [Atualizado em: 19/10/2022]

O Dependabot atualiza as dependências @types junto com os pacotes correspondentes em projetos TypeScript. Antes dessa mudança, os usuários veriam solicitações de pull separadas para um pacote e o pacote @types correspondente. Este recurso é habilitado automaticamente para repositórios contendo pacotes @types no devDependencies do projeto dentro do arquivo package.json. Você pode desabilitar esse comportamento definindo o campo ignore em seu arquivo dependabot.yml como @types/*. Para obter mais informações, confira "Sobre as atualizações de versão do Dependabot" e "Opções de configuração para o arquivo dependabot.yml ".

O GitHub Actions pode impor revisões de dependência nas solicitações de pull dos usuários ao verificar as dependências e avisar os usuários sobre vulnerabilidades de segurança associadas. A ação dependency-review-action é suportada por um novo ponto de extremidade da API que diferencia as dependências entre duas revisões. Para obter mais informações, confira "Sobre a revisão de dependência".

O grafo de dependência detecta os arquivos Cargo.toml e Cargo.lock para Rust. Esses arquivos serão exibidos na seção Grafo de dependência da guia Insights. Os usuários receberão alertas e atualizações do Dependabot para vulnerabilidades associadas às dependências do Rust. Os metadados de pacote, incluindo pacotes de mapeamento para repositórios, serão adicionados posteriormente. Para obter mais informações, confira "Sobre o grafo de dependência".

Se o GitHub Connect estiver habilitado para sua instância, os usuários poderão contribuir com uma melhoria para um aviso de segurança no Banco de dados de avisos do GitHub. Para contribuir, clique em Sugerir melhorias para esta vulnerabilidade enquanto visualiza os detalhes de um aviso. Para obter mais informações, consulte os seguintes artigos.

• "Como gerenciar o GitHub Connect"
• "Como procurar vulnerabilidades de segurança no Banco de Dados de Consultoria do GitHub" na documentação do GitHub Enterprise Cloud
• "Sobre os Avisos de Segurança do GitHub para repositórios" na documentação do GitHub Enterprise Cloud
• "Como editar os avisos de segurança no Banco de Dados de Consultoria do GitHub" na documentação do GitHub Enterprise Cloud

Em um fluxo de trabalho que chama o fluxo de trabalho reutilizável, os usuários podem passar os segredos para o fluxo de trabalho reutilizável com secrets: inherit. Para obter mais informações, confira "Como reutilizar fluxos de trabalho".

Ao usar o GitHub Actions, os proprietários corporativos e os administradores de repositório podem impedir que o Actions crie solicitações pull para reduzir o risco de mesclar uma alteração que não foi revisada por outra pessoa em uma ramificação protegida. Os proprietários da organização podiam habilitar essa restrição anteriormente. Para obter mais informações, consulte os seguintes artigos.

• "Como aplicar políticas para o GitHub Actions na sua empresa"
• "Como desabilitar ou limitar o GitHub Actions para sua organização"
• "Como gerenciar as configurações do GitHub Actions para um repositório"

Os usuários podem escrever um único fluxo de trabalho disparado por workflow_dispatch e workflow_call e usar o contexto inputs para acessar os valores de entrada. Anteriormente, as entradas workflow_dispatch estavam na carga do evento, o que aumentava a dificuldade para autores de fluxo de trabalho que queriam escrever um fluxo de trabalho que fosse reutilizável e acionado manualmente. Para fluxos de trabalho disparados por workflow_dispatch, as entradas ainda estão disponíveis no contexto github.event.inputs para manter a compatibilidade. Para obter mais informações, confira "Contextos".

Para resumir o resultado de um trabalho, os usuários podem gerar Markdown e publicar o conteúdo como um resumo do trabalho. Por exemplo, após a execução de testes com o GitHub Actions, um resumo pode fornecer uma visão geral dos testes aprovados, reprovados ou ignorados, reduzindo potencialmente a necessidade de revisar toda a saída do log. Para obter mais informações, confira "Comandos de fluxo de trabalho do GitHub Actions".

Para diagnosticar de forma mais fácil as falhas de execução do trabalho durante uma nova execução do fluxo de trabalho, os usuários podem habilitar o log de depuração, que gera informações de saída sobre a execução e o ambiente de um trabalho. Para obter mais informações, confira "Executar novamente fluxos de trabalho e trabalhos" e "Como usar logs de execução de fluxo de trabalho".

Se você gerenciar executores auto-hospedados para o GitHub Actions, poderá garantir um estado consistente no próprio executor antes e depois da execução do fluxo ao definir os scripts a serem executados. Ao usar scripts, você não precisa mais exigir que os usuários incorporem manualmente essas etapas nos fluxos de trabalho. Os scripts pré e pós trabalho estão em versão beta e estão sujeitos a alterações. Para obter mais informações, confira "Como executar scripts antes ou depois de um trabalho".

Os proprietários corporativos podem migrar imagens de contêiner do registro do GitHub Docker para o registro do GitHub Container. O registro de contêiner oferece os benefícios a seguir.

• Melhora o compartilhamento de contêineres dentro de uma organização
• Permite a aplicação de permissões de acesso granular
• Permite o compartilhamento anônimo de imagens de contêineres públicos
• Implementa padrões OCI para hospedar imagens do Docker

O registro de contêineres está em versão beta e sujeito a alterações. Para mais informações, confira "Como migrar sua empresa para o registro de contêiner do Registro do Docker".

As discussões do GitHub estão disponíveis no GitHub Enterprise Server. As discussões do GitHub oferecem um espaço de reunião central para fazer perguntas, compartilhar ideias e criar conexões. Para obter mais informações, confira "Discussões do GitHub".

Os proprietários de empresas podem configurar uma política para controlar se os nomes de usuário ou nomes completos das pessoas são exibidos em repositórios internos ou públicos. Para obter mais informações, confira "Como impor políticas de gerenciamento de repositório na sua empresa".

Os usuários podem criar LEIAMEs somente para membros para uma organização. Para obter mais informações, confira "Personalizar o perfil da sua organização".

Os proprietários da organização podem fixar um repositório no perfil da organização diretamente do repositório por meio do novo menu suspenso Fixar repositório. Os repositórios públicos fixados aparecem para todos os usuários da sua instância, enquanto os repositórios públicos, privados e internos são visíveis apenas para os membros da organização.

Ao criar uma bifurcação, os usuários podem personalizar o nome da bifurcação. Para obter mais informações, confira "Criar um fork de um repositório".

Os usuários podem excluir uma ramificação associada a uma solicitação pull aberta. Para obter mais informações, confira "Como criar e excluir branches no seu repositório".

Os repositórios com várias licenças exibem todas as licenças na barra lateral "Sobre" na guia Código . Para obter mais informações, confira "Licenciamento de um repositório".

Os usuários podem exigir uma implantação bem-sucedida de uma ramificação antes que alguém possa mesclar a solicitação de pull associada à ramificação. Para obter mais informações, confira "Sobre os branches protegidos" e "Como gerenciar uma regra de proteção de branch".

Os proprietários corporativos podem impedir que os proprietários da organização convidem colaboradores para repositórios na instância. Para obter mais informações, confira "Como impor uma política para convidar colaboradores para repositórios".

Os usuários podem conceder exceções ao GitHub Apps para qualquer regra de proteção de ramificação compatível com as exceções. Para obter mais informações, confira "Sobre apps" e "Como gerenciar uma regra de proteção de branch".

Para chaves de assinatura GPG públicas expiradas ou revogadas, o GitHub Enterprise Server verifica as assinaturas de confirmação do Git e mostra as confirmações como verificadas se o usuário fez a confirmação enquanto a chave ainda era válida. Os usuários também podem fazer upload de chaves GPG expiradas ou revogadas. Para obter mais informações, confira "Sobre a verificação de assinatura de commit".

Para afirmar que a confirmação está em conformidade com as regras e licenciamento que regem um repositório, agora os proprietários da organização e os administradores do repositório podem exigir que os desenvolvedores assinem as confirmações realizadas por meio da interface da web. Para obter mais informações, confira "Como gerenciar a política de aprovação de commit da sua organização" e "Como gerenciar a política de aprovação de commit do seu repositório".

Ao usar a árvore de arquivos localizada na guia Arquivos alterados de uma solicitação de pull, os usuários podem navegar pelos arquivos modificados, entender o tamanho e o escopo das alterações e se concentrar nas revisões. A árvore de arquivos aparece se uma solicitação de pull modificar pelo menos dois arquivos e a janela do navegador for suficientemente ampla. Para obter mais informações, confira "Como revisar as alterações propostas em uma solicitação de pull" e "Como filtrar arquivos em uma solicitação de pull".

Os usuários podem usar como padrão os títulos de solicitações de pull como a mensagem de confirmação para todas as mesclagens squash. Para obter mais informações, confira "Como configurar o squash de commit para solicitações de pull".

No GitHub Mobile para iOS 1.80.0 e posteriores, os usuários podem editar arquivos dentro do branch de tópicos de uma solicitação de pull. O suporte para edição de arquivos chegará ao GitHub Mobile para Android em uma versão futura. [Atualizado em: 13/09/2022]

Ao visualizar os detalhes de uma versão específica, os usuários podem ver a data de criação de cada ativo da versão. Para obter mais informações, confira "Como ver as versões e as marcas do repositório".

Ao criar uma versão com notas de versão geradas automaticamente, os usuários podem ver a marca identificada como a versão anterior e selecionar uma marca diferente para especificar como a versão anterior. Para obter mais informações, confira "Notas sobre a versão geradas automaticamente".

A edição do Markdown na interface da web foi aprimorada.

• Depois que o usuário seleciona o texto e cola uma URL, o texto selecionado se tornará um link Markdown da URL colada.
• Quando o usuário cola células de planilha ou tabelas HTML, o texto resultante será renderizado como uma tabela.
• Quando o usuário copia texto contendo links, o texto colado incluirá o link como um link Markdown.

Para obter mais informações, confira "Sintaxe básica de escrita e formatação".

Ao editar um arquivo Markdown na interface da web, se você clicar na guia Visualizar ela rolará automaticamente até o local na visualização que você estava editando. O local de rolagem é baseado na posição do cursor antes de você clicar na guia Visualizar.

O protocolo Git não criptografado e não autenticado agora está desabilitado por padrão. Se você não reabilitar o protocolo depois de atualizar para o GitHub Enterprise Server 3.6 ou posterior, as conexões git:// na porta 9418 retornarão o erro a seguir.

The unauthenticated git protocol on port 9418 is no longer supported.

Se você deseja dar suporte ao protocolo em seu ambiente, você precisa reabilitar manualmente o recurso. Para obter mais informações, confira "Como impor políticas de gerenciamento de repositório na sua empresa" e o Blog do GitHub. [Atualizado em 31-01-2023]

Elementos interativos na interface da Web, como links e botões, mostram um contorno visível quando focados com o teclado, para ajudar os usuários a encontrar a posição atual na página. Além disso, quando focados, os campos de formulário têm um contorno de contraste mais elevado.

Se um usuário atualizar a página ao criar um novo problema ou solicitação de pull, os responsáveis, revisores, rótulos e projetos serão preservados.

Agora há suporte para o hipervisor VMware vSphere ESXi versão 7.0. [Atualizado em: 07-09-2022]

Em uma instância de GitHub Enterprise Server recém-configurada sem usuários, um invasor pode criar o primeiro usuário administrador.

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

Os arquivos rastreados do Git LFS carregados por meio da interface da Web são adicionados incorretamente de maneira direta ao repositório.

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

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

O registro npm GitHub Packages não retorna mais um valor temporal em respostas de metadados. Isso foi feito para permitir melhorias substanciais de desempenho. Continuamos a ter todos os dados necessários para retornar um valor temporal como parte da resposta de metadados e continuaremos a retornar este valor no futuro quando tivermos resolvido os problemas de desempenho existentes.

Os limites de recursos que são específicos para processamento de ganchos de pré-recebimento podem causar falha em alguns ganchos de pré-recebimento.

Os serviços de ação devem ser reiniciados após a restauração do dispositivo a partir do backup tomado em um host diferente.

Nas configurações de um repositório, habilitar a opção de permitir que usuários com acesso de leitura criem discussões não habilita esta funcionalidade.

Em alguns casos, os usuários não podem converter problemas existentes em discussões.

Padrões personalizados para verificação de segredo têm .* como um delimitador final, especificamente no campo "Depois do segredo". Esse delimitador causa inconsistências nas verificações de segredos nos repositórios e você pode notar lacunas no histórico de um repositório em que nenhuma verificação foi concluída. As verificações incrementais também podem ser afetadas. Para evitar problemas com verificações, modifique o final do padrão para remover o delimitador .*.

Em alguns casos, os clientes do GitHub Advanced Security que fizerem upgrade para o GitHub Enterprise Server 3.6 poderão perceber que os alertas de verificação de segredo estarão ausentes na interface do usuário da Web e na API REST. Para garantir que os alertas permaneçam visíveis, não ignore a versão 3.4 ao atualizar para a versão mais recente. Para planejar uma atualização até a versão 3.4, confira o Assistente de atualização.

• Para exibir os alertas ausentes para todos os repositórios pertencentes a uma organização, os proprietários da organização podem navegar até as configurações de Segurança e análise de código da organização e clicar em Habilitar todos para verificação de segredo. Para obter mais informações, confira "Gerenciando as configurações de segurança e de análise da sua organização".
• Para exibir os alertas ausentes de um repositório individual, as pessoas com acesso de administrador ao repositório podem desabilitar e habilitar a verificação secreta do repositório. Para obter mais informações, confira "Gerenciando as configurações de segurança e análise do repositório".

Uma correção está disponível na versão de patch 3.6.1. [Atualizado em: 09/01/2022]

Depois de atualizar um nó de réplica do GitHub Enterprise Server 3.6.0 ou posteriores e reiniciar a replicação, a replicação do Git pode interromper o progresso e continuar a mostrar WARNING: git replication is behind the primary …. Se você encontrar esse problema conhecido, entre em contato com Suporte do GitHub Enterprise. [Atualizado em: 03/10/2022]

As compilações do GitHub Pages podem atingir o tempo limite em instâncias da AWS configuradas para alta disponibilidade. [Atualizado em: 2022-11-28]

Instâncias com um alto número sustentado de solicitações simultâneas do Git podem ter problemas de desempenho. Se você suspeitar que esse problema está afetando sua instância, entre em contato com Suporte do GitHub. Para obter mais informações, confira "Criando um tíquete de suporte". [Atualizado em: 12/07/2022]

Para os participantes na versão beta privada do SCIM do GitHub Enterprise Server, não há suporte para mapeamentos personalizados dos atributos de usuário SAML nesta versão. Há suporte para mapeamentos personalizados no GitHub Enterprise Server 3.6.5 ou 3.7.5 e posterior. [Atualizado em 27-02-2023]

No caso das instâncias em uma configuração de alta disponibilidade, as operações git push podem falhar nas situações a seguir. [Atualizado em 17-03-2023]

• Durante a criação do repositório em um nó de réplica
• Após uma falha ao criar o repositório em um nó de réplica, antes do reparo automático do repositório