Enterprise Server 3.7 release notes

MEDIUM: tokens de instalação com escopo para um Aplicativo GitHub mantiveram as permissões aprovadas depois que as permissões na instalação de integração foram rebaixadas ou removidas. O GitHub solicitou a ID CVE CVE-2023-23765 para essa vulnerabilidade, que foi relatada por meio do programa de Recompensas por Bugs do GitHub.

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

Em uma instância em uma configuração de cluster, ao atualizar o nó master do MySQL, a execução da configuração pós-atualização levaria 600 segundos a mais do que o necessário devido à detecção incorreta de nós não íntegros.

Em algumas situações em uma instância com vários nós, a replicação do Git não conseguiu replicar totalmente os repositórios que haviam sido excluídos anteriormente, o que resultou em um aviso na saída ghe-repl-status.

Em uma instância com o grafo de dependência habilitado, o caminho correto é exibido para manifestos originados de instantâneos de envio em tempo de compilação.

Pessoas com acesso SSH administrativo a uma instância podem configurar o uso máximo de memória em gigabytes para Redis usando ghe-config redis.max-memory-gb VALUE.

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

MEDIUM: atualização do Git para incluir correções de 2.40.1. Para obter mais informações, confira Vulnerabilidades de segurança do Git anunciadas no Blog do GitHub.

Os usuários não puderam carregar arquivos GIF como anexos em um comentário em um problema ou uma solicitação de pull.

Em uma instância em uma configuração de alta disponibilidade, podia ocorrer uma falha em uma operação git push se o GitHub Enterprise Server estivesse criando simultaneamente o repositório em um nó de réplica.

Um administrador do site não pôde ignorar um proxy para um TLD (domínio de nível superior) da lista de exceções da instância ou TLDs (domínios de nível superior registrados por IANAs).

Em algumas plataformas, depois que alguém com acesso SSH administrativo executou ghe-diagnostics, a saída do comando incluiu um erro cosmético SG_IO.

Em alguns casos, em uma instância com uma licença de GitHub Advanced Security, os usuários não puderam carregar a página de análise de segurança e viram o erro 500.

Quando um administrador do site usou o GitHub Enterprise Importer para importar dados do GitHub Enterprise Cloud, as migrações falharam durante a importação de comentários no nível do arquivo. Essa falha não impede mais que a importação prossiga.

Em uma instância com uma licença de GitHub Advanced Security, os usuários com a função de gerente de segurança de uma organização não puderam exibir configurações GitHub Advanced Security para a organização.

Se um usuário clicou no link para compartilhar comentários ou relatar bugs para a versão beta das listas de usuários, a interface da Web respondeu com um erro 404.

Quando um administrador do site usou o GitHub Enterprise Importer, a importação de um repositório falhou se uma coluna de projeto no repositório continha 2.500 ou mais cartões arquivados.

Em uma instância com alertas do Dependabot habilitados, os alertas eram erroneamente ocultos quando diferentes vulnerabilidades eram detectadas por vários detectores de envio em tempo de build.

O GitHub Enterprise Server publicava métricas de distribuição que não podem ser processadas pelo collectd. As métricas incluíam pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids e git.hooks.runtime.

Em alguns casos, em uma instância com o GitHub Actions habilitado, a implantação do site GitHub Pages usando um fluxo de trabalho GitHub Actions falhou com um status de deployment_lost.

Em uma instância com uma licença GitHub Advanced Security que também foi configurada para um fuso horário maior que UTC, a lista de alertas de verificação de segredo exibia um erro "Falha ao carregar segredos" se um usuário classificasse segredos por data em ordem decrescente.

Em uma instância com o grafo de dependência habilitado, os serviços em segundo plano podem lidar com mais tráfego.

Pessoas com acesso SSH administrativo que gera um pacote de suporte usando os utilitários ghe-support-bundle ou ghe-cluster-support-bundle pode especificar o período de tempo para coletar dados com -p ou --period sem usar espaços ou aspas. Por exemplo, além de '-p 5 days' ou -p '4 days 10 hours', -p 5days ou -p 4days10hours são válidos.

Em uma instância com o GitHub Actions habilitado, as chamadas aninhadas a fluxos de trabalho reutilizáveis em um trabalho de fluxo de trabalho reutilizável com uma matriz avaliam corretamente os contextos dentro de expressões, como strategy: ${{ inputs.strategies }}.

As solicitações de download para objetos do Git LFS não foram concluídas até relatar o tamanho final do download, o que afetou a latência dessas solicitações, especialmente na instância com nós funcionando como caches de repositório.

Para instâncias com o GitHub Connect e o acesso automático a ações de GitHub.com habilitadas, o Dependabot não atualizaria as ações hospedadas no GitHub.com.

Em alguns casos, em uma instância com uma licença de GitHub Advanced Security, os usuários não puderam carregar a página de análise de segurança e viram o erro 500.

Em uma instância com o GitHub Connect habilitado, se a opção "Os usuários podem pesquisar o GitHub.com" estivesse habilitada, os problemas em repositórios privados e internos não seriam incluídos nos resultados da pesquisa no GitHub.com.

Após a restauração de uma organização excluída, a organização não aparece na lista de organizações da instância.

Os logs coletados podem crescer rapidamente em tamanho devido à inclusão de métricas kredz.*, que não podem ser analisadas pelo StatsD e resultaram em mensagens de erro.

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.

Se o administrador do site fornecer uma configuração inválida no armazenamento de blobs para GitHub Actions ou Pacotes do GitHub em uma instância, a página de verificações de simulação exibirá detalhes e informações de solução de problemas.

ALTO: abordou uma vulnerabilidade de autenticação inadequada que permitia que um ator não autorizado modificasse os gists secretos de outros usuários autenticando-se por meio de uma autoridade de certificação SSH. Essa vulnerabilidade foi relatada por meio do  Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-23761. [Atualizado em 07-04-2023]

MÉDIO: abordou uma vulnerabilidade de comparação incorreta que permitia o contrabando de commit exibindo uma comparação incorreta. Essa vulnerabilidade foi relatada por meio do  Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-23762. [Atualizado em 07-04-2023]

Em uma instância com o GitHub Actions habilitado, as chamadas aninhadas a fluxos de trabalho reutilizáveis em um trabalho de fluxo de trabalho reutilizável com uma matriz avaliam corretamente os contextos dentro de expressões, como strategy: ${{ inputs.strategies }}.

Em uma instância em uma configuração de alta disponibilidade, podia ocorrer uma falha em uma operação git push se o GitHub Enterprise Server estivesse criando simultaneamente o repositório em um nó de réplica.

No painel do monitor do console de gerenciamento, os grafos Cached Requests e Served Requests, que são recuperados pelo comando git fetch catching, não exibiam as métricas da instância.

Depois que um administrador do site isentou o usuário @github-actions[bot] da limitação de taxa usando o comando ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]", a execução de ghe-config-check gerou o aviso Validation is-valid-characterset failed.

O GitHub Actions (actions) e o Microsoft SQL (mssql) não apareciam na lista de processos no painel do monitor de instâncias.

Em alguns casos, ocorria uma falha de renderização dos grafos no painel do monitor do console de gerenciamento.

Em uma instância em uma configuração de alta disponibilidade, se um administrador desativou a replicação de um nó de réplica usando ghe-repl-teardown imediatamente após a execução de ghe-repl-setup, mas antes de ghe-repl-start, um erro indica que o script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown agora exibe um alerta informativo e continua a desativação.

Depois que um administrador usava o ponto de extremidade /setup/api/start da API REST para carregar uma licença, ocorria uma falha na execução da configuração com o erro Connection refused durante a fase de migrações.

Em uma instância em uma configuração de cluster, quando um administrador do site definiu o modo de manutenção usando ghe-maintenance -s, um erro Permission denied foi exibido quando o utilitário tentou acessar /data/user/common/cluster.conf.

Durante a configuração de alta disponibilidade, se um administrador do site interrompia o utilitário ghe-repl-start, o utilitário relatava erroneamente que a replicação foi configurada e a instância não executava as operações de limpeza esperadas.

Nas instâncias configuradas para usar a versão beta privada do SCIM para o GitHub Enterprise Server, ocorria uma falha na autenticação dos usuários com chaves SSH e tokens de acesso pessoal devido a um requisito incorreto de autorização.

Depois que um usuário importava um repositório com a proteção por push habilitada, o repositório não ficava imediatamente visível na exibição "Cobertura de Segurança" da visão geral de segurança.

As respostas do ponto de extremidade /repositories da API REST incluíam erroneamente os repositórios excluídos.

Quando um administrador do site usou ghe-migrator para migrar dados para o GitHub Enterprise Server, em alguns casos, as relações de equipe aninhada não eram persistidas após a importação das equipes.

Se um repositório continha um arquivo CODEOWNERS com anotações de marcação, a guia "Arquivos alterados" das solicitações de pull retornava o erro 500 e exibia "Opa, algo deu errado" na seção "Arquivos inalterados com anotações de marcação".

Em uma instância com o GitHub Actions habilitado, se um usuário disparava manualmente um fluxo de trabalho usando a API REST, mas não especificava valores para boolianos opcionais, a API não conseguia validar a solicitação e retornava o erro 422.

Os relatórios CSV para todos os usuários e todos os usuários ativos, disponíveis no painel de administração do site, não consideravam o acesso recente usando o SSH ou os tokens de acesso pessoal.

Em alguns casos, em uma instância com vários nós, o GitHub Enterprise Server interrompia erroneamente a gravação nos servidores de arquivos de réplica, fazendo com que os dados do repositório ficassem fora de sincronia.

O GitHub Enterprise Server publicava métricas de distribuição que não podem ser processadas pelo collectd. As métricas incluíam pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids e git.hooks.runtime.

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.

O proprietário da empresa não pode habilitar a 2FA (autenticação de dois fatores) para a instância se algum proprietário da empresa não tiver habilitado a 2FA para as contas de usuário. [Atualizado em 17-04-2023]

Em uma instância com pacotes do GitHub habilitados, depois que os usuários enviaram por push para o Registro de Contêiner, a instância respondeu erroneamente com um erro 429 Too Many Requests nos casos em que a instância poderia acomodar a solicitação. Os limites foram elevados e os usuários devem receber essa mensagem com menos frequência. [Atualizado: 2023-05-30]

Quando a API de envio de dependência receber um envio com uma ou mais dependências sem uma versão, o grafo de dependência já relatará corretamente esse fato.

Para evitar uma falha durante uma execução de configuração em um cluster, a validação de cluster.conf com o utilitário ghe-cluster-config-check garante que o campo consul-datacenter de cada nó corresponda ao campo primary-datacenter de nível superior.

Em uma instância em uma configuração de cluster, quando um administrador do site define o modo de manutenção em um só nó de cluster usando ghe-maintenance -s, o utilitário avisa o administrador para usar ghe-cluster-maintenance -s a fim de definir o modo de manutenção em todos os nós de clusters. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".

Quando um administrador do site configura um servidor proxy Web de saída para o GitHub Enterprise Server, a instância já valida os TLDs (domínios de nível superior) excluídos da configuração de proxy. Por padrão, você pode excluir os TLDs públicos especificados pela IANA. Os administradores do site podem especificar uma lista de TLDs não registrados a serem excluídos usando ghe-config. O prefixo . é necessário para todos os TLDs públicos. Por exemplo, .example.com é válido, mas example.com é inválido. Para obter mais informações, confira "Configurando um servidor proxy Web de saída".

Para evitar problemas intermitentes com o sucesso das operações do Git em uma instância com vários nós, o GitHub Enterprise Server verifica o status do contêiner do MySQL antes de tentar executar uma consulta SQL. A duração do tempo limite também foi reduzida.

O caminho padrão para a saída de ghe-saml-mapping-csv -d é /data/user/tmp em vez de /tmp. Para obter mais informações, confira "Utilitários de linha de comando".

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. 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. [Atualizado em 10-03-2023]

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.

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

ALTA: foi identificada uma vulnerabilidade de transversalidade de caminho no GitHub Enterprise Server que permitia a leitura arbitrária de arquivos 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 por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2023-22380.

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.

Para instâncias com o GitHub Connect e o acesso automático a ações de GitHub.com habilitadas, o Dependabot não atualizaria as ações hospedadas no GitHub.com.

O arquivo CSV contendo detalhes sobre os colaboradores do GitHub Advanced Security não poderia ser baixado se a instância não tivesse uma licença do GitHub Advanced Security.

Os logs coletados podem crescer rapidamente em tamanho devido à inclusão de métricas kredz.*, que não podem ser analisadas pelo StatsD e resultaram em mensagens de erro.

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.

Depois que a API REST de envio de dependência receber um envio com uma ou mais dependências sem uma versão, o grafo de dependência agora relatará corretamente esse fato.

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.

As chaves SSH e os tokens de acesso pessoal (clássico) falhavam ao permitir o acesso da API REST aos recursos da organização quando o GitHub Enterprise Server fosse configurado com SCIM.

Depois de desabilitar as atualizações do Dependabot, o avatar do Dependabot foi exibido como o usuário @ghost na linha do tempo de alerta do Dependabot.

Em alguns casos, os usuários podem encontrar um erro 500 ao visualizar a página de configurações de Segurança e análise de código para uma instância com um número muito alto de committers ativos.

Alguns links para entrar em contato com o suporte do GitHub ou visualizar as notas de versão do GitHub Enterprise Server estavam incorretos.

A contagem de committers adicionais para GitHub Advanced Security sempre mostrava 0.

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.

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.

Alguns serviços se conectaram incorretamente diretamente ao kafka-lite em vez de usar o proxy interno. Em um ambiente de cluster no qual os serviços Web e de trabalho são executados em nós separados, as mensagens geradas do serviço de trabalho do Insights não foram entregues ao kafka-lite.

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.

A classificação e a filtragem da lista de padrões personalizados para verificação de segredo no nível da organização não funcionou corretamente.

Depois de atualizar para o GitHub Enterprise Server 3.7, a exibição da página de configurações de segurança de uma organização ou repositório pode resultar em um erro 500 devido a um trabalho de provisionamento do GitHub Advanced Security não estar concluído antes do início da atualização.

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

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.

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.

Durante a fase de validação de uma execução de configuração, pode ocorrer um erro No such object nos serviços Notebook e Viewscreen. Esse erro pode ser ignorado, pois os serviços ainda devem ser iniciados corretamente.

Após uma atualização para o GitHub Enterprise Server 3.6 ou posterior, as inconsistências existentes em um repositório, como referências inválidas ou objetos ausentes, agora podem ser relatadas enquanto erros como invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file ou Zero-length loose object file. Anteriormente, esses indicadores de corrupção do repositório podiam ser silenciosamente ignorados. O GitHub Enterprise Server agora usa uma versão atualizada do Git que habilita relatórios de erros mais diligentemente. Para obter mais informações, confira commit de upstream no projeto Git.

Se você suspeita que exista um problema como esse em um de seus repositórios, entre em contato com o suporte do GitHub Enterprise para obter assistência.

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]

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

No caso das instâncias em uma configuração de alta disponibilidade, os administradores de site só devem executar os comandos ghe-repl-start e ghe-repl-stop enquanto elas estiverem no modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção" e "Sobre a configuração de alta disponibilidade." [Atualizado em 17-03-2023]

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. Esta vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e foi designada como CVE-2022-46256.

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

Quando um administrador de site executou o comando ghe-repl-status em uma réplica de cache por meio do shell administrativo (SSH), o comando relatou incorretamente as informações gerais de status de replicação de cluster Git e 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 replicou os certificados para todos os nós de réplica disponíveis.

Em uma configuração de alta disponibilidade, após a promoção de uma réplica para ser o nó primário, um administrador do site não pôde forçar a replicação a parar em um nó de réplica secundário usando o comando ghe-repl-stop -f.

Ao usar cache de 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 buscaria objetos do nó primário da instância em vez do nó de réplica de 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 desabilitado globalmente.

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

Adicionar um colaborador a uma bifurcação de propriedade do usuário de um repositório privado de propriedade da organização com triagem, manutenção ou acesso personalizado resultou 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.

Ignorar um alerta do Dependabot que continha determinados caracteres poderá resultar em um erro 400.

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

Em uma instância que usa SAML para autenticação, o menu suspenso Configurar SSO apareceu erroneamente para tokens de acesso pessoal e chaves SSH.

Uma atualização do GitHub Enterprise Server 3.5 para a 3.7 pode falhar porque a instância ainda não havia apagado repositórios excluídos.

Em uma configuração de cache de repositório ou alta disponibilidade, os serviços do Unicorn em nós diferentes do nó primário não puderam enviar eventos de log para o nó primário.

Corrige um bug no qual um arquivo de log GHES pode ser preenchido muito rapidamente e fazer com que a unidade raiz fique sem espaço livre.

Ao exibir os resultados da verificação de código para Ruby, um rótulo beta errôneo apareceu.

Depois que um proprietário da empresa habilita 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 na empresa com o SCIM". [Atualizado em 27-02-2023]

ALTO: uma neutralização imprópria de delimitadores de argumento em uma vulnerabilidade de comando identificada no GitHub Enterprise Server permitia a execução remota de código. Para explorar essa vulnerabilidade, um invasor precisaria de permissão para criar e compilar o GitHub Pages usando o GitHub Actions. Esse bug foi originalmente relatado por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23740. [Atualizado em: 02-12-2022]

ALTO: uma verificação foi adicionada no Pages para garantir que o diretório de trabalho esteja limpo antes da descompactação do novo conteúdo a fim de evitar um bug arbitrário de substituição de arquivo. Essa vulnerabilidade recebeu a designação CVE-2022-46255.

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. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub.

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

A execução do comando ghe-spokesctl retornava um erro failed to get repo metrics.

A definição do modo de manutenção com uma lista de exceção de IP não era persistida 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.

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

Em uma instância com o GitHub Packages configurados, o upload e a instalação de pacotes podia falhar para clientes que usavam uma URL de ponto de extremidade VPC para o Armazenamento de Blobs do AWS S3.

Em alguns casos, após a atualização para o GitHub Enterprise Server 3.7.0, os usuários podem encontrar erros Internal Server Error ou 500 ao iniciar operações do Git via SSH ou HTTPS.

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.

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.

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.

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.

Durante a fase de validação de uma execução de configuração, pode ocorrer um erro No such object nos serviços Notebook e Viewscreen. Esse erro pode ser ignorado, pois os serviços ainda devem ser iniciados corretamente.

Após uma atualização para o GitHub Enterprise Server 3.6 ou posterior, as inconsistências existentes em um repositório, como referências inválidas ou objetos ausentes, agora podem ser relatadas enquanto erros como invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file ou Zero-length loose object file. Anteriormente, esses indicadores de corrupção do repositório podiam ser silenciosamente ignorados. O GitHub Enterprise Server agora usa uma versão atualizada do Git que habilita relatórios de erros mais diligentemente. Para obter mais informações, confira commit de upstream no projeto Git.

Se você suspeita que exista um problema como esse em um de seus repositórios, entre em contato com o suporte do GitHub Enterprise para obter assistência.

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]

Ao validar as configurações de domínio em uma instância com TLS e isolamento de subdomínio habilitados, o Console de Gerenciamento não exibe os dois novos subdomínios do GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME e http(s)://viewscreen.HOSTNAME, na lista de domínios. [Atualizado em 12/01/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

No caso das instâncias em uma configuração de alta disponibilidade, os administradores de site só devem executar os comandos ghe-repl-start e ghe-repl-stop enquanto elas estiverem no modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção" e "Sobre a configuração de alta disponibilidade." [Atualizado em 17-03-2023]

Para aumentar a segurança do Console de Gerenciamento, os administradores do site podem configurar o limite de taxa das tentativas de entrada, bem como a duração do bloqueio depois de exceder o limite de taxa. Para obter mais informações, confira "Como configurar limites de taxa".

Os requisitos mínimos de senha para o Console de Gerenciamento são mais rigorosos.

As tentativas de autenticação no Console de Gerenciamento e as alterações feitas por um administrador do site no Console de Gerenciamento são gravadas em um arquivo de log no /var/log/enterprise-manage/audit.log.

O Azure Mapas substitui o MapBox na renderização de arquivos GeoJSON como mapas gráficos. Os administradores podem habilitar a renderização de mapa e fornecer um token do Azure Mapas no Console de Gerenciamento. Para obter mais informações, confira "Como administrar sua instância no Console de Gerenciamento".

Os usuários podem verificar os commits usando uma chave pública SSH. Para obter mais informações, confira "Sobre a verificação de assinatura de commit".

Os administradores de sites podem provisionar automaticamente usuários e grupos em uma instância do GitHub Enterprise Server com o SCIM. O SCIM para GitHub Enterprise Server está em versão beta privada e sujeito a alterações. Para obter mais informações, confira "Como configurar o provisionamento de usuário com o SCIM na sua empresa" e "SCIM" na documentação da API REST.

Os usuários em uma instância com uma licença do GitHub Advanced Security podem exibir e comentar os alertas de verificação de código do repositório na guia Conversa da solicitação de pull. Se a regra de proteção de branch Exigir resolução de conversa antes de mesclar estiver habilitada para o repositório, todos os comentários sobre esses alertas de verificação de código deverão ser resolvidos antes que um usuário mescle a solicitação de pull. Para obter mais informações, confira "Sobre a verificação de código", "Sobre revisões de solicitação de pull" e "Sobre branches protegidos".

Para simplificar a distribuição da verificação de segredo para instâncias com dezenas, centenas ou até milhares de organizações, os proprietários corporativos em uma instância com uma licença do GitHub Advanced Security podem habilitar a verificação de segredo e a proteção por push para a instância usando a interface da Web. Para obter mais informações, confira "Como gerenciar os recursos do GitHub Advanced Security para sua empresa".

Os proprietários da organização em uma instância com uma licença do GitHub Advanced Security podem executar uma simulação de padrões personalizados para verificação de segredo para todos os repositórios em uma organização. Para obter mais informações, confira "Como definir padrões personalizados para a verificação de segredos".

Se um administrador do site tiver habilitado notificações por email para uma instância com uma licença do GitHub Advanced Security, os usuários que assistirem aos alertas de verificação de segredo de um repositório receberão uma notificação por email quando um colaborador ignorar um segredo bloqueado pela proteção por push. Anteriormente, as notificações não eram enviadas se o segredo fosse marcado como falso positivo ou usado em testes. Para obter mais informações, confira "Como proteger pushes com verificação de segredo" e "Como configurar emails para notificações".

Para facilitar o gerenciamento de dezenas ou centenas de padrões personalizados para verificação de segredos, usuários, proprietários da organização ou de empresas em uma instância com uma licença do GitHub Advanced Security podem classificar e filtrar a lista de padrões para um repositório, organização ou toda a instância. 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 que protegem pushes com verificação de segredo podem especificar um link personalizado que será exibido na mensagem de erro quando a proteção por push detectar e bloquear um segredo em potencial. Para obter mais informações, confira "Como proteger os pushes com a verificação de segredos".

Os usuários podem publicar pacotes CodeQL no registro de contêiner. Para obter mais informações, confira Como criar e trabalhar com pacotes CodeQL na documentação da CLI do CodeQL.

Os usuários em uma instância com uma licença do GitHub Advanced Security podem usar pacotes CodeQL com verificação de código, incluindo pacotes publicados no registro de Contêiner do GitHub da instância. Para obter mais informações, confira "Como configurar a verificação de código" e Como publicar e usar pacotes CodeQL" na documentação da CLI do CodeQL.

Os usuários em uma instância com uma licença do GitHub Advanced Security podem excluir consultas CodeQL desnecessárias para verificação de código usando filtros de consulta. Para obter mais informações, confira "Como configurar a verificação de código".

Os proprietários corporativos em uma instância com uma licença do GitHub Advanced Security podem recuperar os resultados de verificação de código para toda a instância usando a API REST. O novo ponto de extremidade complementa os pontos de extremidade existentes para repositórios e organizações. Para saber mais, confira "Verificação do código" na documentação de API REST.

Os proprietários da organização em uma instância com uma licença do GitHub Advanced Security podem recuperar o status de habilitação ou configurar a habilitação automática dos recursos a seguir usando a API REST.

• Segurança Avançada do GitHub
• Verificação de segredo
• Proteção por push

Para obter mais informações, confira "Organizações" na documentação da API REST.

Os usuários em uma instância com uma licença do GitHub Advanced Security podem usar cursores para paginar os resultados do alerta de verificação secreta recuperados com a organização da API REST e os pontos de extremidade do repositório. Para saber mais, confira "Verificação de segredo" na documentação de API REST.

A visão geral de segurança da instância inclui informações sobre o Dependabot. Para obter mais informações, confira "Como exibir a visão geral de segurança".

Os usuários podem ver mais informações sobre a atividade associada a um alerta do Dependabot. Dentro dos detalhes de um alerta do Dependabot, os usuários podem ver uma linha do tempo de eventos, como quando o alerta é aberto, corrigido ou reaberto. Os eventos também mostrarão os metadados adicionais quando disponíveis, como solicitações de pull relevantes. Para saber mais, confira "Sobre os alertas do Dependabot".

Os alertas do Dependabot dos usuários são classificados por importância por padrão. A importância considera o CVSS como o fator primário, bem como o risco potencial, a relevância e a facilidade de correção da vulnerabilidade. O cálculo melhorará ao longo do tempo.

Os usuários podem classificar os alertas do Dependabot pelo escopo da dependência, seja em runtime ou desenvolvimento.

Como opção, os usuários podem adicionar um comentário ao ignorar um alerta do Dependabot. Os comentários ao ignorar aparecem na linha do tempo do evento e no campo dismissComment no objeto RepositoryVulnerabilityAlert da API do GraphQL. Para obter mais informações sobre a API do GraphQL, confira "Objetos" na documentação da API do GraphQL.

Os usuários podem selecionar vários alertas do Dependabot e dispensar ou reabrir 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.

Os proprietários da organização em uma instância podem recuperar o status de habilitação ou configurar a habilitação automática dos recursos a seguir para gerenciamento de dependências usando a API REST.

• Gráfico de dependências
• Alertas do Dependabot
• Atualizações de segurança do Dependabot

Para obter mais informações, confira "Organizações" na documentação da API REST.

Proprietários corporativos e de organização, além de gerentes de segurança, podem acessar uma exibição centralizada de risco em toda a instância. A exibição também inclui uma exibição centrada em todos os alertas de verificação de código, verificação de segredo e Dependabot. Os proprietários da empresa podem exibir alertas de organizações das quais são proprietários. Proprietários de organizações e gerentes de segurança podem visualizar repositórios e alertas para as organizações às quais eles têm acesso total. Para obter mais informações, confira "Sobre a visão geral de segurança".

Os proprietários da organização podem organizar equipes de gerentes de segurança usando a API REST. Para obter mais informações, confira "Gerentes de segurança" na documentação da API REST.

Os usuários podem aproveitar as melhorias a seguir no Banco de Dados de Consultoria do GitHub.

• Os usuários podem encontrar avisos de malware pesquisando por type:malware.
• O banco de dados exibe avisos sobre vulnerabilidades do GitHub Actions.

Para obter mais informações, confira "Procurar avisos de segurança no Banco de Dados de Avisos do GitHub".

Os usuários podem preencher o gráfico de dependência de um repositório enviando-as para o repositório usando a API REST. O gráfico de dependência alimenta os alertas e as atualizações de segurança do Dependabot. Para saber mais, confira "Usar a API de envio de dependência".

O GitHub Actions dá suporte ao Google Cloud Storage como um provedor de armazenamento para logs, artefatos e caches. Para obter mais informações, confira "Como habilitar o GitHub Actions com o Google Cloud Storage".

Os usuários do GitHub Actions que usam o cache de dependência para acelerar os fluxos de trabalho agora podem usar a CLI do GitHub para gerenciar o cache do GitHub Actions em um repositório. Para gerenciar caches usando a CLI do GitHub, instale a extensão gh-actions-cache. Para obter mais informações, confira a documentação do gh-actions-cache.

O fluxo de trabalho é executado novamente no GitHub Actions usando o ator que inicialmente disparou o fluxo de trabalho para avaliação de privilégios. O ator que disparou a nova execução continuará a ser exibido na interface do usuário e poderá ser acessado em um fluxo de trabalho por meio do campo triggering_actor no contexto github. Para mais informações, confira "Como reexecutar fluxos de trabalho e tarefas" e "Contextos".

Os usuários podem chamar fluxos de trabalho reutilizáveis de uma matriz ou outros fluxos de trabalho reutilizáveis. Para obter mais informações, confira "Como reutilizar fluxos de trabalho".

Ao consultar o GitHub Actions por artefatos, a API REST retorna informações sobre a execução e o branch que produziram o artefato. Para obter mais informações, confira "Artefatos do GitHub Actions" na documentação da API REST.

Para dar suporte a implantações de nuvem seguras em escala, os proprietários da organização e os administradores do repositório podem concluir as tarefas a seguir com a API REST do OpenID Connect. Para obter mais informações, confira "OIDC do GitHub Actions" na documentação da API REST

• Habilite uma configuração padrão do OpenID Connect entre fluxos de trabalho de implantação de nuvem personalizando o formato de declaração subject.
• Garanta conformidade e segurança adicionais para implantações do OpenID Connect acrescentando a URL issuer com a campo de dados dinâmico da empresa.
• Configure as políticas avançadas do OpenID Connect usando declarações adicionais de token do OpenID Connect, como repository_id e repo_visibility.

Para obter mais informações, confira "Sobre a proteção de segurança com o OpenID Connect".

Os usuários do GitHub Actions que usam o cache de dependência para acelerar os fluxos de trabalho agora podem usar a API REST do Cache do GitHub Actions para realizar as tarefas a seguir.

• Liste todos os caches em um repositório e classifique por metadados.
• Exclua uma entrada de cache corrompida ou obsoleta. Para obter mais informações, confira "Como armazenar em cache dependências para acelerar fluxos de trabalho" e "Cache do GitHub Actions" na documentação da API REST.

Se um executor de GitHub Actions auto-hospedado não efêmero não se comunicar com a instância do GitHub Enterprise Server por mais de 14 dias, a instância removerá o executor automaticamente. Se um executor auto-hospedado efêmero não se comunicar com a instância por mais de um dia, a instância removerá o executor automaticamente. Anteriormente, o GitHub Enterprise Server removeu os executores após 30 dias. Para obter mais informações, confira "Sobre os executores auto-hospedados".

O GitHub Actions pode executar fluxos de trabalho macOS auto-hospedados em um runtime macOS ARM64 com suporte de executor para Apple Silicon, como o chip M1 ou M2. Para saber mais, confira "Usar executores auto-hospedados em um fluxo de trabalho".

Os usuários podem implantar um site do GitHub Pages diretamente de um repositório usando o GitHub Actions sem configurar uma fonte de publicação. O uso do GitHub Actions fornece controle sobre a estrutura e a versão de autoria, bem como mais controle sobre o processo de publicação com recursos como portas de implantação. Para obter mais informações, confira "Como configurar uma fonte de publicação para o seu site do GitHub Pages."

Os proprietários corporativos podem impedir que os usuários criem repositórios de propriedade de suas contas de usuário. Para obter mais informações, confira "Como impor políticas de gerenciamento de repositório na sua empresa".

Os proprietários da empresa podem controlar onde os usuários podem criar forks nos repositórios. A criação de fork pode ser limitada a combinações predefinidas das organizações, à mesma organização que o repositório pai, às contas de usuários ou a todos os lugares. Para obter mais informações, confira "Como impor políticas de gerenciamento de repositório na sua empresa".

Os administradores do repositório podem bloquear pushes potencialmente destrutivos limitando o número de branches e tags que podem ser atualizados por um único push. Por padrão, não há limite para o número de branches e marcas que podem ser atualizados em um único push. Para obter mais informações, confira "Como gerenciar a política de push para seu repositório".

Os usuários podem personalizar ainda mais a mensagem de confirmação padrão ao mesclar uma solicitação de pull. Para obter mais informações, confira "Como configurar a mesclagem de commit para solicitações de pull" e "Como configurar o squashing de commit para solicitações de pull".

Os usuários podem criar um branch na página de visão geral branches de um repositório clicando no botão Novo branch . Para obter mais informações, confira "Como criar e excluir branches no seu repositório".

Quando o usuário renomeia ou move um arquivo para um novo diretório, se pelo menos metade do conteúdo do arquivo for idêntico, o histórico de commit indica que o arquivo foi renomeado, semelhante ao git log --follow. Para obter mais informações, confira o Blog do GitHub. [Atualizado em 10-02-2023]

Foram feitas melhorias na criação e gerenciamento de forks.

• Ao bifurcar um repositório, os usuários podem optar por incluir apenas o branch padrão do repositório na bifurcação.
• Os usuários podem usar o botão Fork do repositório para ver os forks existentes do repositório.
• O botão Buscar upstream foi renomeado como Bifurcação de sincronização para descrever melhor o comportamento dele. Se a sincronização causar um conflito, a interface do usuário da Web solicitará que o usuário contribua com alterações no repositório pai, descarte as alterações ou resolva o conflito.
• Para resolver situações em que as pessoas trabalham em uma organização e não querem criar fork em um repositório para uma conta de organização ou de usuário diferente, os usuários podem criar fork em um repositório para a mesma organização que o repositório pai.
• Os usuários podem criar fork em um repositório interno para outra organização e o fork manterá a visibilidade interna. Ao criar fork em um repositório interno, os usuários podem escolher qual organização deve ser proprietária do fork.

Para obter mais informações, confira "Criar um fork de um repositório".

Os administradores do repositório podem bloquear a criação de branches que correspondam a um padrão de nome configurado com a regra de proteção de ramificação Restringir pushes que criam ramificações correspondentes. Por exemplo, se um branch padrão do repositório mudar de master para main, o administrador do repositório pode impedir qualquer criação ou push subsequente do branch master. Para obter mais informações, confira "Sobre os branches protegidos" e "Como gerenciar uma regra de proteção de branch".

Os usuários podem criar arquivos com diagramas geoJSON, topoJSON e STL e renderizar os diagramas na interface da Web. Para obter mais informações, confira "Como trabalhar com arquivos que não são de código".

Os usuários podem criar referências de link automático usando identificadores alfanuméricos ou numéricos. Para obter mais informações, confira "Como configurar links automáticos para referenciar links automáticos de recursos externos".

Os usuários podem personalizar exclusões no localizador de arquivos como vendor/ e build/ usando os atributos linguist em um arquivo .gitattributes. Para obter mais informações, confira "Como localizar arquivos no GitHub" e "Personalizar como os arquivos alterados aparecem no GitHub".

Os usuários podem procurar os arquivos modificados em um commit individual usando o modo de exibição de árvore. Para obter mais informações, confira "Sobre commits".

Os usuários podem vincular manualmente branches ou solicitações de pull existentes a um problema na seção "Desenvolvimento" na barra lateral do problema. Para obter mais informações, confira "Como vincular uma solicitação de pull a um problema".

Os usuários podem usar a sintaxe Mermaid ao escrever Markdown, que exibe um diagrama ao renderizar o Markdown. Para obter mais informações, confira "Como criar diagramas".

Os usuários podem escrever expressões matemáticas usando blocos de código cercados com a sintaxe math, além dos delimitadores existentes. $$ não é necessário com esse método. Para obter mais informações, confira "Como escrever expressões matemáticas".

• Observação: esse recurso não está disponível no GitHub Enterprise Server 3.7. Este recurso estará disponível em uma versão futura. [Atualizado em: 16/11/2022]

Os usuários podem renderizar mapas diretamente no Markdown usando blocos de código cercados com a sintaxe geojson ou topojson e inserir renderizações STL 3D usando a sintaxe stl. Para obter mais informações, confira "Como criar diagramas".

No Markdown, os usuários podem escrever a sintaxe no estilo LaTeX para renderizar expressões matemáticas embutidas usando delimitadores $ ou em blocos usando delimitadores $$. Para obter mais informações, confira "Como escrever expressões matemáticas".

Para melhorar a estabilidade, o serviço para renderizar GeoJSON, Jupyter Notebook, PDF, PSD, SVG, SolidWorks e outros formatos binários foi substituído.

Se o TLS e isolamento de subdomínio estiverem configurados para sua instância e seu certificado não for um certificado curinga, você deverá gerar um novo certificado que inclua os subdomínios adicionais para esses serviços, notebooks.HOSTNAME e viewscreen.HOSTNAME. Para obter mais informações, confira "Como habilitar o isolamento de subdomínio". [Atualizado em: 12/02/2022]

A verificação de segredo não dá mais suporte a padrões personalizados que usam .* como um delimitador final no campo "Depois do segredo", pois a sintaxe do padrão causaria problemas de verificação e inconsistências.

Ao criar uma nova versão, os usuários agora podem enviar o formulário usando Ctrl + Enter no macOS ou Ctrl + Enter no Windows ou Linux.

A guia Wiki em um repositório só aparece quando existir um wiki. Anteriormente, a guia sempre aparecia.

Os wikis renderizados exibem expressões matemáticas e diagramas do Mermaid.

Aumento do tamanho do campo de pesquisa para logs de auditoria do usuário, da organização e da empresa.

O número máximo de executores em um grupo de executores é limitado a 10.000. Anteriormente, não havia limite. Atualizado: 2023-05-24]

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.

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.

Durante a fase de validação de uma execução de configuração, pode ocorrer um erro No such object nos serviços Notebook e Viewscreen. Esse erro pode ser ignorado, pois os serviços ainda devem ser iniciados corretamente.

Em alguns casos, após a atualização para o GitHub Enterprise Server 3.7.0, os usuários podem encontrar erros Internal Server Error ou 500 ao iniciar operações git do Git via SSH ou HTTPS. Exemplo:

git push origin master
Total 0 (delta 0), reused 0 (delta 0)
remote: Internal Server Error
To ghes.hostname.com:User/repo.git
! [remote rejected]       master -> master (Internal Server Error)

Se eles forem encontrados, entre em contato com o suporte do GitHub Enterprise com um pacote de suporte. A solução temporária conhecida no omento é reiniciar o serviço github-gitauth com os comandos abaixo:

nomad stop github-gitauth
nomad run /etc/nomad-jobs/github/gitauth.hcl
nomad status github-gitauth

No momento, estamos investigando uma correção permanente para um patch dinâmico futuro [Atualizado: 24/11/2022].

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]

Ao validar as configurações de domínio em uma instância com TLS e isolamento de subdomínio habilitados, o Console de Gerenciamento não exibe os dois novos subdomínios do GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME e http(s)://viewscreen.HOSTNAME, na lista de domínios. [Atualizado em 12/01/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

No caso das instâncias em uma configuração de alta disponibilidade, os administradores de site só devem executar os comandos ghe-repl-start e ghe-repl-stop enquanto elas estiverem no modo de manutenção. Para obter mais informações, confira "Habilitar e programar o modo de manutenção" e "Sobre a configuração de alta disponibilidade." [Atualizado em 17-03-2023]

An upgrade to GitHub Enterprise Server 3.6 or 3.7 from 3.5 or earlier may be long running if a large number of deleted repositories exist. Deleted repositories are purged automatically after 90 days, but for a faster upgrade they can be purged manually. If you suspect you have thousands of recently deleted repositories, and you are concerned about a long running upgrade, contact GitHub Enterprise Support for assistance purging deleted repositories. [Updated: 2023-05-09]

Substituição futura: no GitHub Enterprise Server 3.8 e posterior, os algoritmos não seguros serão desabilitados para conexões SSH com o shell administrativo.

Os comentários de commit, que são adicionados pelos usuários diretamente a um commit fora de uma solicitação de pull, não aparecem mais na linha do tempo da solicitação de pull. Os usuários não puderam responder ou resolver esses comentários. A API REST de eventos da Linha do Tempo e o objeto PullRequest da API do GraphQL também não retornam mais comentários de commit.

A diferenciação de arquivos GeoJSON, PSD e STL não é mais possível.

Os registros de pacote na nova arquitetura de GitHub Packages, incluindo o registro de Contêiner e pacotes npm, não expõem mais dados por meio da API do GraphQL. Em uma versão futura, outros registros de Pacotes do GitHub serão migrados para a nova arquitetura, o que também substituirá a API do GraphQL para esses registros.