Enterprise Server 3.4 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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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 para os serviços de contêiner github (renomeado com base nos metadados), gitauth e unicorn não eram lidas corretamente do collectd e exibidas no console de gerenciamento.

Os repositórios bloqueados para migração permitiam a edição dos arquivos na IU da Web.

O comando git-janitor não conseguia corrigir arquivos multi-pack-index.lock desatualizados, o que resultava em falha na manutenção do repositório.

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

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

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.

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 um hora. Anteriormente, o link de arquivo morto expirava após cinco minutos.

HIGH: A path traversal vulnerability was identified in GitHub Enterprise Server that allowed remote code execution when building a GitHub Pages site. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the instance. This vulnerability was reported via the GitHub Bug Bounty Program and has been assigned CVE-2022-46256.

HIGH: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2022-23741.

When a site administrator ran the ghe-repl-sync-ca-certificates command from an instances primary node via the administrative shell (SSH), the command only replicated CA certificates from the instances primary node to a single replica node. The command did not replicate the certificates to all available replica nodes.

Installation of GitHub Enterprise Server on the VMware ESXi hypervisor failed due to the generation of an OVA file with an invalid capacity value.

When users performed an operation using the API, GitHub Enterprise Server enforced repository size quotas even when disabled globally.

The member webhook event did not include the from and to field values for the permission field as part of the changes field.

After a user's account was deleted from the instance, image attachments that the user uploaded in comments were no longer visible in the web interface.

A debug-level message appeared in a system log, which could consume space rapidly on the instance's root storage volume.

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

Se GitHub Actions foi configurado com o armazenamento de blobs S3 para a instância, conteúdo como logs e artefatos de execuções de fluxo de trabalho excluídas ou expiradas permanecerão no armazenamento de blobs indefinidamente. A instância excluirá esse conteúdo automaticamente na próxima vez que um trabalho regular de limpeza em segundo plano for executado.

Definir o modo de manutenção com uma lista de exceção de IP não persistiria nas atualizações.

As compilações do GitHub Pages podem atingir o tempo limite em instâncias da AWS configuradas para alta disponibilidade.

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.

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

Em alguns casos, os usuários não puderam mesclar uma solicitação de pull devido a verificações de status inesperadas.

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

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

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.

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

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

Para garantir que os administradores de site possam concluir uma atualização com sucesso, 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 GitHub pode 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 ajustar a escala de privilégios.

MÉDIO: o uso de um caractere de substituição Unicode da direita para a esquerda na lista de arquivos acessíveis para um Aplicativo GitHub pode obscurecer arquivos adicionais que o aplicativo poderia acessar.

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

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

Falha na instalação de um certificado TLS quando a cadeia de caracteres de assunto dele 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 por meio de ghe-config.

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.

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 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 renderizar uma exibição incorreta.

Clones ou buscas do Git por meio de SSH podiam gerar dados corrompidos em transferências com mais de 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.

Depois de atualizar para o GitHub Enterprise Server 3.4, as versões parecerão estar ausentes dos repositórios. Isso ocorreu enquanto as migrações de índice do Elasticsearch necessárias não foram concluídas com êxito. A interface do usuário das versões agora indica se está aguardando a conclusão das migrações de índice do Elasticsearch e links para a documentação sobre como observar o status e concluir imediatamente a migração.

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.

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.

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.

Ao adicionar um membro a uma organização, um convite de avaliação de SSO do SAML errôneo apareceu.

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.

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

CRÍTICO: o contêiner do Elasticsearch para GitHub Enterprise Server usava uma versão do OpenJDK 8 que era vulnerável a um problema de truncamento de inteiros ao processar folhas de estilo XSLT mal-intencionadas. A vulnerabilidade recebeu a designação CVE-2022-34169.

ALTO: os aplicativos instalados anteriormente em uma conta de usuário recebiam automaticamente permissão para acessar uma organização em tokens de acesso com escopo definido depois que essa era transformada em uma conta de organização. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub.

Em alguns casos, ocorria uma falha na inicialização das instâncias do GitHub Enterprise Server no AWS que usavam o tipo de instância r4.4xlarge.

Ao calcular os committers para a Segurança Avançada do GitHub, não foi possível especificar repositórios individuais. Para obter mais informações, confira "Painel de administração do site".

Quando um limite de inatividade personalizado foi definido para a instância, a suspensão de todos os usuários inativos não respeitou o limite de maneira confiável. Para saber mais sobre inatividade, confira "Sobre os usuários inativos".

Os eventos pre_receive_hook.rejected_push não eram exibidos no log de auditoria da empresa.

Ambos os arquivos da migração para repositórios e exportações de arquivo para contas de usuároi incluem reações de liberação.

MÉDIO: impede um ataque em que uma SSRF (falsificação de solicitação do lado do servidor) poderia forçar a ponte SVN (Subversion) a executar códigos remotos injetando dados arbitrários no Memcached.

MÉDIO: impede que um invasor execute código Javascript explorando uma vulnerabilidade de XSS (cross-site scripting) em elementos de IU suspensos na interface da Web do GitHub Enterprise Server.

Atualiza o Grafana para a versão 7.5.16, que lida com várias vulnerabilidades de segurança, incluindo CVE-2020-13379 e CVE-2022-21702.

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

MÉDIO: uma vulnerabilidade de XSS armazenado identificada no GitHub Enterprise Server permitia a injeção de atributos arbitrários. Essa injeção foi bloqueada pela CSP (Política de Segurança de Conteúdo) do Github. Essa vulnerabilidade foi relatada por meio do Programa de Recompensas por Bugs do GitHub e recebeu a designação CVE-2022-23733. [Atualizado em 31-07-2022]

MÉDIO: uma vulnerabilidade envolvendo a desserialização de dados não confiáveis foi identificada no GitHub Enterprise Server que poderia levar à execução de código remota na ponte SVN (Subversion). Para explorar essa vulnerabilidade, um invasor precisaria obter acesso por meio de uma SSRF (solicitação forjada do lado do servidor) que permitiria que um invasor controlasse os dados que estão sendo desserializados. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs do GitHub e foi designada como CVE-2022-23734.

Em alguns casos, o daemon collectd pode consumir memória em excesso.

Em alguns casos, os backups de arquivos de log rotacionados podem acumular e consumir armazenamento em excesso.

Após uma atualização para uma nova versão de recurso e a subsequente execução da configuração, o Elasticsearch pode registrar exceções excessivas durante a reconstrução de índices.

Em alguns casos em que um branch protegido exigia mais de uma revisão de aprovação, uma solicitação de pull poderia ser mesclada com um número menor que o necessário de revisões de aprovação.

Em instâncias que usam a autenticação LDAP, o prompt de autenticação para o modo sudo colocou incorretamente o cursor no campo de senha por padrão quando os campos de texto para nome de usuário e senha estavam visíveis.

Em alguns casos, os fluxos de trabalho agendados do GitHub Actions podem ser desabilitados.

O ponto de extremidade "Cobrança" da API de cobrança agora retorna cabeçalhos Link para fornecer informações sobre paginação.

O ponto de extremidade "Cobrança" da API de cobrança agora retorna o número correto de committers totais.

O utilitário de linha de comando ghe-set-password inicia os serviços necessários automaticamente quando a instância é inicializada no modo de recuperação.

As métricas para processos aqueduct em segundo plano são reunidas para o encaminhamento pelo Collectd e exibidas no console de gerenciamento.

O local do log de execução de configuração e migração do banco de dados, /data/user/common/ghe-config.log, agora é exibido na página que detalha uma migração em andamento.

MÉDIO: evita um ataque em que um parâmetro de cadeia de caracteres de consulta org pode ser especificado para uma URL do GitHub Enterprise Server que dá acesso a committers ativos de outra organização.

MÉDIO: garante que github.company.com e github-company.com não sejam avaliados por serviços internos como nomes de host idênticos, a fim de evitar um possível ataque de SSRF (falsificação de segurança do lado do servidor).

BAIXO: um invasor podia acessar o Console de Gerenciamento com um ataque de passagem de caminho via HTTP, mesmo que regras de firewall externas bloqueassem o acesso HTTP.

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

Os arquivos dentro de um arquivo de artefatos não puderam ser abertos após a descompactação devido a permissões restritivas.

Os tempos limite do Redis não interrompem mais as migrações do banco de dados durante a execução de ghe-config-apply.

Os processadores de trabalho em segundo plano ficariam presos em um estado parcialmente desligado, resultando em certos tipos de trabalhos em segundo plano (como varredura de código) parecendo travados.

Em alguns casos, os administradores do site não foram adicionados automaticamente como proprietários da empresa.

Um problema de renderização pode afetar a lista suspensa para filtrar alertas de verificação secreta em um repositório.

Desempenho aprimorado das atualizações de versão do Dependabot após a primeira ativação.

Os tempos limite de compilação e sincronização do GitHub Pages agora são configuráveis no Management Console.

A criação ou atualização de execuções de verificação ou conjuntos de verificação podia retornar 500 Internal Server Error quando o valor de determinados campos, como o nome, era muito longo.

Ao implantar os nós do servidor de cache, agora é obrigatório descrever a topologia do datacenter (usando o argumento --datacenter) para cada nó no sistema. Esse requisito evita situações em que deixar a associação de datacenter definida como "padrão" faz com que as cargas de trabalho sejam balanceadas inadequadamente em vários datacenters.

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

Um script interno para validar nomes do host no arquivo de configuração do GitHub Enterprise Server retornaria um erro se a cadeia de caracteres do nome do host começasse com "." (caractere de ponto).

Nas configurações de HA em que o nome do host primário tiver mais que 60 caracteres, a configuração do MySQL falhará.

Quando GitHub Actions foi habilitado, mas o TLS estava desabilitado no GitHub Enterprise Server 3.4.1 e posteriores, a aplicação de uma atualização de configuração iria falhar.

O argumento --gateway foi adicionado ao comando ghe-setup-network para permitir a transmissão do endereço do gateway ao definir as configurações de rede por meio da linha de comando.

Os pontos de extremidade da API de cobrança do GitHub Advanced Security não estavam habilitados e acessíveis.

Os anexos de imagem excluídos retornavam um erro 500 Internal Server Error em vez de um erro 404 Not Found.

Em ambientes configurados com um servidor de cache de repositório, o comando ghe-repl-status mostrava incorretamente os gists como sub-replicados.

Os pontos de extremidade "Obter um commit" e "Comparar dois commits" na API Commit retornaria o erro 500 se o caminho de um arquivo no diff contivesse um caractere unicode codificado e de escape.

O cálculo de "máximo de committers na instância inteira" relatado no painel do administrador do site estava incorreto.

Uma entrada incorreta no banco de dados de réplicas de repositórios corrompeu o banco de dados ao executar uma restauração usando GitHub Enterprise Server Backup Utilities.

Não foi exibida a linha do tempo da atividade para alertas de digitalização de segredos.

A inclusão de métricas ao gerar um pacote de suporte de cluster foi otimizada.

Em configurações de alta disponibilidade em que o Elasticsearch relatava um status amarelo válido, as alterações introduzidas em uma correção anterior bloqueavam o comando ghe-repl-stop e não permitiam a interrupção da replicação. O uso de ghe-repo-stop --force agora forçará a parada do Elasticsearch quando o serviço estiver nos status normal ou amarelo válido.

MÉDIO: foi identificado um problema de segurança no resolvedor do Nginx em que um invasor que fosse capaz de forjar pacotes UDP do servidor DNS poderia causar uma substituição de memória de 1 byte, que resultava em falhas no processo de trabalho ou em outros impactos potencialmente prejudiciais. A vulnerabilidade recebeu a designação CVE-2021-23017.

As ações actions/checkout@v2 e actions/checkout@v3 foram atualizadas para resolver novas vulnerabilidades anunciadas na postagem no blog de imposição de segurança do Git.

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

Em algumas topologias de cluster, o comando ghe-cluster-status deixava diretórios vazios em /tmp.

O SNMP registrava incorretamente um grande número de mensagens de erro Cannot statfs no syslog.

Ao adicionar padrões personalizados e fornecer cadeias de caracteres de teste que não sejam UTF8, a correspondência do realce estava incorreta.

Usuários LDAP com caractere sublinhado (_) em seus nomes de usuários agora podem fazer logon com sucesso.

Para instâncias configuradas com autenticação SAML e fallback integrado habilitado, os usuários integrados ficariam presos em um loop de "login" ao tentar entrar na página gerada após o logout.

Após habilitar as instruções criptografadas de SAML com o Azure como provedor de identidade, a página de logon falhará apresentando o erro 500.

As preferências de atalhos chave de teclado não foram respeitadas.

As tentativas de exibir a saída git fsck da página /stafftools/repositories/:owner/:repo/disk falhavam com um 500 Internal Server Error.

Ao usar declarações criptografadas SAML, algumas delas não marcavam corretamente as chaves SSH como verificadas.

Os vídeos enviados para emitir comentários não seriam renderizados corretamente.

Ao usar o Importador do GitHub Enterprise para importar um repositório, alguns problemas causariam falha na importação devido a eventos de linha do tempo de projeto configurados incorretamente.

Ao usar ghe-migrator, uma migração não conseguia importar anexos de arquivos de vídeo em problemas e solicitações de pull.

A página Versões retornava o erro 500 quando o repositório apresentava marcas com caracteres não ASCII. [Atualizado em: 10/06/2022]

As atualizações falhariam algumas vezes ao migrar dados de grafo de dependência. [Atualizado em: 30/06/2022]

Em configurações de alta disponibilidade, esclareça que a página de visão geral da replicação no Console de Gerenciamento exibe apenas a configuração de replicação atual, não o status de replicação atual.

O tempo limite de alocação do Nomad para o Grafo de dependência foi aumentado para garantir que seja possível concluir as migrações após a atualização.

Ao habilitar GitHub Packages, esclareça que o uso de um token de SAS (Assinatura de Acesso Compartilhado) como cadeia de conexão não tem suporte no momento.

Os pacotes de suporte agora incluem a contagem de linhas de tabelas armazenadas no MySQL.

Ao determinar em quais redes de repositório será agendada a manutenção, não contamos mais o tamanho dos objetos inacessíveis.

O campo de resposta run_started_at agora está incluído na API de Execuções de Fluxo de Trabalho e no conteúdo do webhook de eventos workflow_run.

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

Foi resolvida uma regressão que poderia levar a falhas consistentes na recuperação de artefatos e no download de arquivos de log para o GitHub Actions. Em algumas circunstâncias, as URLs de comunicações internas que usavam localhost paravam de ser resolvidas e, em vez disso, o nome do host da instância era usado incorretamente.

Quando um arquivo de manifesto fosse excluído de um repositório, o manifesto não seria removido da página “Grafo de dependência” do repositório.

Atualizar os nós em um par de alta disponibilidade com um pacote de atualização poderia fazer com que o Elasticsearch entrasse em um estado inconsistente em alguns casos.

Arquivos de log rotacionados com a extensão .backup se acumulavam em diretórios com logs do sistema.

Em algumas topologias de cluster, os utilitários de linha de comando ghe-spokesctl e ghe-btop falharam ao serem executados.

Os índices do Elasticsearch podiam ser duplicados durante uma atualização de pacote, devido à execução de um serviço elasticsearch-upgrade diversas vezes em paralelo.

Os servidores de cache de repositório poderiam fornecer dados de locais que não estão em cache mesmo quando os dados estivessem disponíveis na localização de cache local.

Ao fazer a conversão de uma conta de usuário para uma organização, se a conta de usuário fosse um proprietário da conta da empresa GitHub Enterprise Server, a organização convertida apareceria incorretamente na lista de proprietário da empresa.

A página /stafftools/users/ip_addresses/:address respondia com um 500 Internal Server Error ao tentar exibir a página de um endereço IPv6.

Criar um token OAuth de representação usando a API REST da Enterprise Administration resultava em um erro quando já existia uma integração correspondendo a ID do OAuth Application.

Suporte adicionado para nomes de domínio de réplica com mais de 63 caracteres.

Agora, a saída do log de configuração e dos erros de configuração que interrompem uma execução de aplicação de configuração é feita no terminal.

Se os recursos do GitHub Advanced Security estiverem habilitados em sua instância, o desempenho dos trabalhos em segundo plano foi aprimorado no processamento de lotes para contribuições ao repositório.

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 GitHub.com" está habilitado com GitHub Connect, os problemas em repositórios privados e internos não são incluídos nos resultados de pesquisa de 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.

Depois de registrar um executor auto-hospedado com o parâmetro --ephemeral em mais de um nível (por exemplo, tanto em empresa quanto em organização), o executor poderá ficar preso em um estado ocioso e precisar de um novo registro. [Atualizado em: 17/06/2022]

Após a atualização para o GitHub Enterprise Server 3.4, aparentemente as versões estarão ausentes dos repositórios. Isso poderá ocorrer enquanto as migrações de índice do Elasticsearch necessárias não forem concluídas com êxito.

Em alguns casos, os clientes do GitHub Advanced Security que fizerem upgrade para o GitHub Enterprise Server 3.5 ou posterior poderão perceber que os alertas da verificação secreta 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 de uma versão anterior para a versão 3.5 ou posterior. Uma correção está disponível nas versões de patch 3.5.5 e 3.6.1.

Para planejar uma atualização até a versão 3.4, confira o Assistente de atualização. [Atualizado em: 09/01/2022]

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

O GitHub Enterprise Server 3.0 foi descontinuado em 16 de fevereiro de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

O GitHub Enterprise Server 3.1 será descontinuado em 3 de junho de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

Começando em GitHub Enterprise Server 3.3, GitHub Enterprise Server no XenServer foi preterido e não é mais compatível. Entre em contato com o Suporte do GitHub em caso de dúvidas ou preocupações.

Devido ao baixo uso, preterimos a versão prévia da API de Referências de Conteúdo em GitHub Enterprise Server 3.4. A API era acessível anteriormente com o cabeçalho corsair-preview. Os usuários podem continuar a navegar para URLs externas com esta API. Qualquer uso registrado da API de Referências de Conteúdo não receberá mais uma notificação de Webhook para URLs dos seus domínios registrados e não retornamos mais códigos de resposta válidos para tentativas de atualizações para anexações de conteúdo existente.

A versão prévia da API de Códigos de Conduta, que era acessível com o cabeçalho scarlet-witch-preview, foi preterida e não está mais acessível no GitHub Enterprise Server 3.4. Como alternativa, é recomendado usar o ponto de extremidade "Obter métricas de perfil da comunidade" para recuperar informações sobre o código de conduta de um repositório. Para saber mais, confira o "Aviso de substituição: versão prévia da API de Códigos de Conduta" no log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.4, a versão preterida dos pontos de extremidade da API de Aplicativo OAuth foi removida. Se você encontrar mensagens de erro 404 nesses pontos de extremidade, converta o código para as versões da API de Aplicativo OAuth que não possuem access_tokens na URL. Também desabilitamos o uso de autenticação de API usando os parâmetros de consulta. Como alternativa, é recomendado usar a autenticação da API no cabeçalho da solicitação.

O executor CodeQL é preterido em GitHub Enterprise Server 3.4 e não é mais compatível. O preterimento somente afeta usuários que usam a verificação de código de CodeQL em sistemas CI/CD de terceiros; os usuários de GitHub Actions não são afetados. Recomendamos que os clientes migrem para a CLI CodeQL, que é uma substituição de recurso completo para o executor CodeQL. Para saber mais, confira o "Log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.1, o suporte a extensões de bit-cache do proprietário do GitHub começou a ser substituído. Essas extensões foram preteridas a partir do GitHub Enterprise Server 3.3.

Quaisquer repositórios presentes e ativos no sua instância do GitHub Enterprise Server que executavam a versão 3.1 ou 3.2 terão sido atualizados automaticamente.

Repositórios que não estavam presentes e ativos antes de atualizar para GitHub Enterprise Server 3.3 podem não desempenhar de modo otimizado até que a tarefa de manutenção de repositório tenha sido executada e concluída com sucesso.

Para iniciar uma tarefa de manutenção de repositório manualmente, acesse https://<hostname>/stafftools/repositories/<owner>/<repository>/network em cada repositório afetado e clique no botão “Agendar”.

O seletor de temas para o GitHub Pages foi removido das Configurações de páginas. Para saber mais sobre a configuração de temas para o GitHub Pages, confira "Adicionar um tema ao site do GitHub Pages usando o Jekyll".

MÉDIO: Foi identificada uma vulnerabilidade transversal de caminho no console de gerenciamento GitHub Enterprise Server que permitia o bypass de proteções CSRF. Esta vulnerabilidade afetou todas as versões de GitHub Enterprise Server anteriores à 3.5 e foi corrigida nas versões 3.1.19, 3.2.11, 3.3.6 e 3.4.1. Essa vulnerabilidade foi relatada pelo Programa de Recompensas por Bugs GitHub e foi designada CVE-2022-23732.

MÉDIO: foi identifica uma vulnerabilidade de estouro de inteiros no branch 1.x e no branch 2.x de yajil que resultava no subsequente corrompimento de memória heap ao lidar com entradas grandes (cerca de 2 GB). Esta vulnerabilidade foi relatada internamente e foi designada CVE-2022-24795.

Pacotes de suporte podem incluir arquivos sensíveis se GitHub Actions foi habilitado.

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

Uma execução de fluxo de trabalho poderá não ser concluída se usar ações compostas.

Ao habilitar Dependabot, um erro fez alguns consultores de segurança serem lidos temporariamente como não mais aplicáveis.

Os processos Minio teriam alto uso de CPU, se uma opção antiga de configuração estivesse presente após atualizar GitHub Enterprise Server.

As opções para habilitar TLS 1.0 e TLS 1.1 nas configurações de privacidade do Console de Gerenciamento eram mostradas, apesar da remoção dessas versões de protocolo em uma versão anterior.

Em um ambiente de alta disponibilidade, configurar a replicação MSSQL poderia exibir etapas manuais adicionais após habilitar GitHub Actions pela primeira vez.

Um subconjunto de arquivos de configuração internos são atualizados de modo mais confiável após um patch dinâmico.

Às vezes, o script ghe-run-migrations não conseguia gerar corretamente os nomes dos certificados temporários.

Os ganchos de pré-recebimento que usavam gpg --import atingiam o tempo limite devido a privilégios syscall insuficientes.

Em algumas topologias de grupo, a informação de entrega de Webhook não estava disponível.

O gráfico de implantação GitHub Actions exibia um erro ao renderizar um trabalho pendente.

As verificações de integridade do Elasticsearch não permitiriam um status de cluster amarelo ao executar migrações.

Ao usar a API de Migrações, os trabalhos de exportação enfileirados não eram processados.

Os repositórios não exibiam uma guia Discussões não-funcional na interface do usuário da Web.

As organizações criadas como resultado de um usuário transformando sua conta de usuário em uma organização não foram adicionadas à conta global da empresa.

Houve falha em trabalhos de sincronização de usuário de LDAP ao tentar sincronizar chaves de GPG que foram sincronizadas anteriormente.

Foram removidos os links para páginas inacessíveis.

Algumas instâncias experimentaram alto uso de CPU devido a grandes quantidades de trabalhos em segundo plano desnecessários sendo colocados em fila.

Os repositórios vazios não sincronizaram corretamente nos servidores de cache.

Acrescentar uma equipe como revisor a uma solicitação de pull, às vezes mostraria o número incorreto de membros daquela equipe.

O ponto de extremidade de API de remover a associação a uma equipe responderia com um erro ao tentar remover o membro gerenciado externamente por meio de um Grupo SCIM.

Um grande número de usuários dormentes poderia fazer com que uma configuração de GitHub Connect falhasse.

A página "Recurso e inscrição beta" na interface do usuário da Web da página do administrador estava incorretamente disponível.

O link "Modo admin do site" no rodapé do site não mudou de estado quando clicado.

Ao usar ghe-migrator ou fazer uma exportação do GitHub.com, a exportação não incluía os anexos da solicitação de pull.

Os limites de conexão armazenados no cache foram aumentados para acomodar melhor as topologias de cluster grande.

A API do grafo de dependência anteriormente era executada com uma porta estaticamente definida.

As contagens do fragmento padrão para as configurações de fragmentos do Elasticsearch relacionadas ao cluster foram atualizadas.

A API de Migrações agora gera exportações de repositórios.

Ao filtrar membros da corporação por função na organização na página "Pessoas", o texto para os itens do menu suspenso foi aprimorado.

As funções de equipe “Triagem” e “Manutenção” são preservadas durante as migrações do repositório.

O desempenho foi melhorado para solicitações de web feitas por proprietários de corporações.

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 GitHub.com" está habilitado com GitHub Connect, os problemas em repositórios privados e internos não são incluídos nos resultados de pesquisa de 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.

Depois de registrar um executor auto-hospedado com o parâmetro --ephemeral em mais de um nível (por exemplo, tanto em empresa quanto em organização), o executor poderá ficar preso em um estado ocioso e precisar de um novo registro. [Atualizado em: 17-06-2022]

Ao usar declarações criptografadas SAML com o GitHub Enterprise Server 3.4.0 e 3.4.1, um novo atributo XML WantAssertionsEncrypted no SPSSODescriptor contém um atributo inválido para metadados SAML. Os IdPs que consomem esse ponto de extremidade de metadados SAML podem encontrar erros ao validar o esquema XML de metadados SAML. Uma correção estará disponível na próxima versão de patch. [Atualizado em: 11-04-2022]

Para solucionar esse problema, é possível executar uma das ações a seguir.

• Reconfigure o IdP carregando uma cópia estática dos metadados SAML sem o atributo WantAssertionsEncrypted.
• Copie os metadados SAML, remova o atributo WantAssertionsEncrypted, hospede-o em um servidor Web e reconfigure o IdP para apontar para a URL.

Em alguns casos, os clientes do GitHub Advanced Security que fizerem upgrade para o GitHub Enterprise Server 3.5 ou posterior poderão perceber que os alertas da verificação secreta 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 de uma versão anterior para a versão 3.5 ou posterior. Uma correção está disponível nas versões de patch 3.5.5 e 3.6.1.

Para planejar uma atualização até a versão 3.4, confira o Assistente de atualização. [Atualizado em: 09/01/2022]

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

O GitHub Enterprise Server 3.0 foi descontinuado em 16 de fevereiro de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

O GitHub Enterprise Server 3.1 será descontinuado em 3 de junho de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

Começando em GitHub Enterprise Server 3.3, GitHub Enterprise Server no XenServer foi preterido e não é mais compatível. Entre em contato com o Suporte do GitHub em caso de dúvidas ou preocupações.

Devido ao baixo uso, preterimos a versão prévia da API de Referências de Conteúdo em GitHub Enterprise Server 3.4. A API era acessível anteriormente com o cabeçalho corsair-preview. Os usuários podem continuar a navegar para URLs externas com esta API. Qualquer uso registrado da API de Referências de Conteúdo não receberá mais uma notificação de Webhook para URLs dos seus domínios registrados e não retornamos mais códigos de resposta válidos para tentativas de atualizações para anexações de conteúdo existente.

A versão prévia da API de Códigos de Conduta, que era acessível com o cabeçalho scarlet-witch-preview, foi preterida e não está mais acessível no GitHub Enterprise Server 3.4. Como alternativa, é recomendado usar o ponto de extremidade "Obter métricas de perfil da comunidade" para recuperar informações sobre o código de conduta de um repositório. Para saber mais, confira o "Aviso de substituição: versão prévia da API de Códigos de Conduta" no log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.4, a versão preterida dos pontos de extremidade da API de Aplicativo OAuth foi removida. Se você encontrar mensagens de erro 404 nesses pontos de extremidade, converta o código para as versões da API de Aplicativo OAuth que não possuem access_tokens na URL. Também desabilitamos o uso de autenticação de API usando os parâmetros de consulta. Como alternativa, é recomendado usar a autenticação da API no cabeçalho da solicitação.

O executor CodeQL é preterido em GitHub Enterprise Server 3.4 e não é mais compatível. O preterimento somente afeta usuários que usam a verificação de código de CodeQL em sistemas CI/CD de terceiros; os usuários de GitHub Actions não são afetados. Recomendamos que os clientes migrem para a CLI CodeQL, que é uma substituição de recurso completo para o executor CodeQL. Para saber mais, confira o "Log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.1, o suporte a extensões de bit-cache do proprietário do GitHub começou a ser substituído. Essas extensões foram preteridas a partir do GitHub Enterprise Server 3.3.

Quaisquer repositórios presentes e ativos no sua instância do GitHub Enterprise Server que executavam a versão 3.1 ou 3.2 terão sido atualizados automaticamente.

Repositórios que não estavam presentes e ativos antes de atualizar para GitHub Enterprise Server 3.3 podem não desempenhar de modo otimizado até que a tarefa de manutenção de repositório tenha sido executada e concluída com sucesso.

Para iniciar uma tarefa de manutenção de repositório manualmente, procure https://<hostname>/stafftools/repositories/<owner>/<repository>/network para cada repositório afetado e clique no botão “Agendar”.

Os clientes do GitHub Advanced Security agora podem usar a API REST para recuperar detalhes da confirmação dos segredos detectados nas verificações do repositório privado. O novo ponto de extremidade retornou detalhes da primeira detecção de um segredo dentro de um arquivo, incluindo a localização do segredo e o SHA de confirmação. Para obter mais informações, confira "Secret scanning" na documentação da API REST.

Os proprietários da empresa e da organização agora podem exportar os dados de uso da sua licença do GitHub Advanced Security para um arquivo CSV. Os dados de cobrança do Advanced Security também podem ser recuperados pelos pontos de extremidade de cobrança na API REST. Para saber mais, confira o "Log de alterações do GitHub".

Agora você pode reutilizar fluxos de trabalho completos como se eles fossem uma ação. Esse recurso está disponível na versão beta pública. Em vez de copiar e colar as definições do fluxo de trabalho entre repositórios, agora você pode referenciar um fluxo de trabalho existente com uma única linha de configuração. Para saber mais, confira o "Log de alterações do GitHub".

O Dependabot está disponível no GitHub Enterprise Server 3.4 como uma versão beta pública e oferece atualizações de versão e de segurança para diversos ecossistemas populares. O Dependabot no GitHub Enterprise Server requer o GitHub Actions e um pool de executores auto-hospedados configurados para uso pelo Dependabot. O Dependabot no GitHub Enterprise Server também requer que o GitHub Connect e o Dependabot sejam habilitados por um administrador. Comentários e sugestões sobre a versão beta podem ser compartilhados na Discussão do GitHub de comentários sobre o Dependabot. Para saber mais e testar a versão beta, confira "Configurar as atualizações de segurança e de versão do Dependabot em sua empresa".

Se você usar a autenticação SAML para o GitHub Enterprise Server, agora poderá configurar declarações criptografadas do seu idP para aprimorar a segurança. Asserções criptografadas adicionam uma camada adicional de criptografia quando seu IdP transmite informações ao sua instância do GitHub Enterprise Server. Para obter mais informações, confira "Como usar o SAML".

No GitHub Mobile para iOS 1.80.0 e posterior, os usuários agora podem editar arquivos dentro da ramificação de tópico 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]

Os usuários agora podem escolher o número de espaços ao qual uma guia equivale, definindo o seu tamanho da guia preferido nas configurações de "Aparência" da sua conta de usuário. Todos os códigos com recuos de guia serão renderizados usando o tamanho preferido da guia.

O registro de conexão de dados do GitHub Connect agora inclui uma contagem do número de usuários ativos e inativos e o período de inatividade configurado.

Você pode dar aos usuários acesso aos links específicos da empresa ao adicionar rodapés personalizados ao GitHub Enterprise Server. Para saber mais, confira "Configurar rodapés personalizados".

O WireGuard, usado para garantir a comunicação entre as instâncias do GitHub Enterprise Server em uma configuração de alta disponibilidade, foi transferido para a implementação do Kernel.

Os proprietários da organização agora podem cancelar a assinatura de notificações por email quando novas chaves de implantação forem adicionadas em repositórios pertencentes às suas organizações. Para obter mais informações, confira "Como configurar notificações".

Os emails de notificação sobre solicitações de pull e problemas recém-criados agora incluem (Issue #xx) ou (PR #xx) no assunto, para facilitar o reconhecimento e a filtragem de emails que fazem referência a esses tipos de problemas.

As organizações agora podem exibir um arquivo README.md na visão geral do perfil. Para saber mais, confira o "Log de alterações do GitHub".

Os membros das organizações agora podem exibir uma lista dos proprietários da empresa na guia "Pessoas" da organização. Além disso, essa lista agora também pode ser acessada usando a API do GraphQL. Para saber mais, confira o campo "enterpriseOwners" no objeto Organização na documentação da API do GraphQL.

Uma seção “Gerenciar acesso” agora é exibida na página “Colaboradores e equipes” nas suas configurações do repositório. A nossa seção facilita que os administradores de repositório vejam e gerenciam quem tem acesso ao seu repositório, e qual nível de acesso é concedido para cada usuário. Agora os administradores podem:

• Pesquise todos os membros, equipes e colaboradores com acesso ao repositório.
• Veja quando os membros têm atribuições de funções mistas, que foram concedidas a eles diretamente como indivíduos ou indiretamente por meio de uma equipe. Isso é exibido pelo novo aviso de “funções mistas”, que mostra a função de nível mais alto concedida ao usuário se o nível de permissão deles for maior do que da função concedida.
• Gerencie o acesso de grandes grupos de usuários a repositórios populares de maneira confiável, com paginação de páginas e menos tempos limite.

O GitHub Enterprise Server 3.4 inclui melhorias na experiência de convite de repositório, como notificações de convites de repositórios privados, uma instrução de interface de usuário ao visitar um repositório privado, para o qual você tem um convite pendente, e um banner na página de visão geral do repositório público quando há um convite pendente.

Agora você pode usar prefixos de caractere único para links automáticos personalizados. Os prefixos de link automático também permitem caracteres ., -, _, +, =, :, / e #, além de caracteres alfanuméricos. Para saber mais sobre os links automáticos personalizados, confira "Configurar links automáticos para referenciar recursos externos”.

Um arquivo CODE_OF_CONDUCT.md na raiz de um repositório agora é realçado na barra lateral "Sobre" na página de visão geral do repositório.

O GitHub Enterprise Server 3.4 inclui melhorias à interface do usuário das versões, como notas sobre a versão geradas automaticamente que exibem um resumo de todas as solicitações de pull para determinada versão. Para saber mais, confira o "Log de alterações do GitHub".

Quando uma versão é publicada, agora é exibida uma lista de avatares na parte inferior da versão. São mostrados avatares para todas as contas de usuário mencionadas nas notas sobre a versão. Para obter mais informações, confira "Como gerenciar as versões do repositório".

Agora você pode usar a página de configurações “Acessibilidade” para gerenciar os atalhos do seu teclado. É possível optar por desabilitar os atalhos de teclado que usam somente caracteres únicos, como S, G C e . (a tecla de ponto final). Para saber mais, confira o "Log de alterações do GitHub".

Agora você pode escolher usar uma fonte de largura fixa nos campos habilitados de markdown, como comentários de problemas e descrições de solicitação de pull. Para saber mais, confira o "Log de alterações do GitHub".

Agora, você pode colar uma URL em um texto selecionado para criar rapidamente um link de Markdown. Isso funciona em campos habilitados para Markdown, como comentários de problemas e descrições de solicitações de pull. Para saber mais, confira o "Log de alterações do GitHub".

Uma URL de imagem agora pode ser anexada com um contexto de tema, como #gh-dark-mode-only, para definir como a imagem Markdown é exibida para um visualizador. Para saber mais, confira o "Log de alterações do GitHub".

Ao criar ou editar um arquivo gist com a extensão de arquivo Markdown (.md), agora é possível usar a guia "Pré-visualização" ou "Pré-visualização de alterações" para exibir uma renderização Markdown do conteúdo do arquivo. Para saber mais, confira o "Log de alterações do GitHub".

Ao digitar o nome de um usuário do GitHub em problemas, solicitações de pull e discussões, o sugestor @mention agora classifica os participantes existentes com mais prioridade do que outros usuários do GitHub, para que seja mais provável que o usuário que você está procurando esteja listado.

Os idiomas da direita para a esquerda agora são compatíveis nativamente em arquivos Markdown, problemas, solicitações de pull, discussões e comentários.

A configuração de comparação para ocultar alterações do espaço em branco na guia “Arquivos alterados” da solicitação de pull agora é retida para a sua conta de usuário para aquela solicitação de pull. A configuração escolhida é reaplicada automaticamente se você navegar para fora da página e depois revisitar a guia "Arquivos alterados" da mesma solicitação de pull.

Ao usar a atribuição automática para revisões de código de solicitação de pull, agora você pode escolher notificar somente os membros da equipe solicitada independentemente das suas configurações de atribuição automática. Essa configuração será útil em cenários onde vários usuários são atribuídos automaticamente, mas nem todos os usuários precisam de notificação. Para saber mais, confira o "Log de alterações do GitHub".

Os administradores de organização e repositório agora podem disparar webhooks que procuram alterações nas regras de proteção de ramificação nos seus repositórios. Para saber mais, confira o evento "branch_protection_rule" na documentação de conteúdos e eventos de webhooks.

Ao configurar ramificações protegidas, agora você poderá impor que uma verificação de estado necessária é fornecida por um GitHub App específico. Se o estado for fornecido por um aplicativo diferente, ou por um usuário via status de confirmação, a mesclagem será impedida. Isso garante que todas as alterações sejam validadas pelo aplicativo pretendido. Para saber mais, confira o "Log de alterações do GitHub".

Agora, somente usuários com permissões de administrador são capazes de renomear as ramificações protegidas e modificar as regras de proteção de ramificação. Anteriormente, com a exceção da ramificação padrão, um colaborador podia renomear uma ramificação e, por consequência, qualquer regra de proteção de ramificação não curinga aplicada para aquela ramificação também era renomeada. Para saber mais, confira "Renomear um branch" e "Gerenciar uma regra de proteção de branch".

Agora, os administradores podem permitir que somente usuários e equipes específicos consigam contornar os requisitos da solicitação de pull. Para saber mais, confira o "Log de alterações do GitHub".

Agora, os administradores podem permitir que somente usuários e equipes específicos forcem o push para um repositório. Para saber mais, confira o "Log de alterações do GitHub".

Ao exigir solicitações de pull para todas as alterações de uma ramificação protegida, os administradores podem agora escolher se revisões aprovadas também são um requisito. Para saber mais, confira o "Log de alterações do GitHub".

Os fluxos de trabalho do GitHub Actions disparados pelo Dependabot para os eventos create, deployment e deployment_status agora sempre recebe um token somente leitura e nenhum segredo. Da mesma forma, os fluxos de trabalho disparados pelo Dependabot para o evento pull_request_target em solicitações de pull em que a referência base foi criada pelo Dependabot sempre recebem um token somente leitura e nenhum segredo. Estas alterações foram projetadas para evitar que código potencialmente malicioso seja executado em um fluxo de trabalho com privilégios. Para obter mais informações, confira "Como automatizar o Dependabot com o GitHub Actions".

As execuções de fluxo de trabalho em eventos push e pull_request disparadas pelo Dependabot agora respeitarão as permissões especificadas nos fluxos de trabalho, permitindo que você controle a maneira como gerencia as atualizações automáticas de dependência. As permissões do token padrão permanecerão como somente leitura. Para saber mais, confira o "Log de alterações do GitHub".

Os fluxos de trabalho do GitHub Actions disparados pelo Dependabot agora receberão os segredos do Dependabot. Agora você pode executar o pull de registros de pacotes privados na sua CI usando os mesmos segredos configurados para o Dependabot usar, melhorando como o GitHub Actions e o Dependabot trabalham em conjunto. Para obter mais informações, confira "Como automatizar o Dependabot com o GitHub Actions".

Agora você pode gerenciar grupos de executores e ver o estado dos seus executores auto-hospedados usando as novas páginas Executores e Grupos de Executores na interface do usuário. A página de configurações Ações do seu repositório ou organização agora mostra uma exibição resumida dos seus executores e permite que você se aprofunde em um executor específico para editá-lo ou ver qual trabalho ele pode estar executando atualmente. Para saber mais, confira o "Log de alterações do GitHub".

Os autores do Actions agora podem executar suas ações no Node.js 16 especificando runs.using como node16 no action.yml das ações. Isso é um acréscimo ao suporte existente do Node.js 12, ou seja, as ações podem continuar a especificar runs.using: node12 para usar o runtime do Node.js 12.

Para fluxos de trabalho disparados manualmente, o GitHub Actions agora dá suporte aos tipos de entrada choice, boolean e environment, além do tipo padrão string. Para obter mais informações, confira "on.workflow_dispatch.inputs".

As ações escritas em YAML, também conhecidas como ações compostas, agora são compatíveis com condicionais if. Isso permite que você impeça que etapas específicas sejam executadas, a menos que uma condição tenha sido atendida. Como etapas definidas em fluxos de trabalho, você pode usar qualquer contexto e expressão compatível para criar uma condicional.

A pesquisa de comportamento do pedido para executores auto-hospedados agora mudou, de modo que o primeiro executor correspondente disponível em qualquer nível executará o trabalho em todos os casos. Isso permite que os trabalhos sejam enviados mais rapidamente para executores auto-hospedados, especialmente para organizações e empresas com muitos executores auto-hospedados. Anteriormente, ao executar um trabalho que exigia um executor auto-hospedado, o GitHub Actions procuraria por executores auto-hospedados no repositório, organização e empresa, nessa ordem.

Os rótulos de executor para executores auto-hospedados de GitHub Actions agora podem ser listados, adicionados e removidos usando a API REST. Para saber como usar as novas APIs no nível de um repositório, organização ou empresa, confira "Repositórios", "Organizações" e "Empresas" na documentação da API REST.

O grafo de dependência agora oferece suporte para a detecção de dependências Python em repositórios que usam o gerenciador de pacotes Poetry. As dependências serão detectadas nos arquivos de manifesto pyproject.toml e poetry.lock.

Ao configurar as atualizações de segurança e de versão do Dependabot no GitHub Enterprise Server, recomendamos também habilitar o Dependabot no GitHub Connect. Isso permitirá que o Dependabot recupere uma lista atualizada de dependências e vulnerabilidade do GitHub.com, consultando informações, como logs de alterações das versões públicas do código-fonte aberto do qual você depende. Para saber mais, confira "Habilitar o gráfico de dependência e os alertas do Dependabot para sua empresa".

Os alertas do Dependabot alerts agora podem ser ignorados usando a API do GraphQL. Para saber mais, confira a mutação "dismissRepositoryVulnerabilityAlert" na documentação da API do GraphQL.

A CLI do CodeQL agora dá suporte até para consulta de ajuda renderizada de markdown em arquivos SARIF, de modo que o texto de ajuda possa ser exibido na interface do usuário do code scanning quando a consulta gerar um alerta. Para saber mais, confira o "Log de alterações do GitHub".

A CLI do CodeQL e a extensão do Visual Studio Code agora dão suporte aos bancos de dados de compilação e análise do código em computadores da plataforma Apple Silicon, como Apple M1. Para saber mais, confira o "Log de alterações do GitHub".

A profundidade da análise do CodeQL foi aprimorada por meio da adição do suporte a mais bibliotecas e estruturas do ecossistema Python. Como resultado, o CodeQL agora pode detectar ainda mais fontes potenciais de dados de usuário não confiáveis, etapas por meio das quais esses dados fluem e coletores potencialmente perigosos onde os dados podem acabar. Isso resulta em uma melhoria geral da qualidade de alertas do code scanning. Para saber mais, confira o "Log de alterações do GitHub".

A verificação de código com CodeQL agora inclui suporte beta para análise de código em todas as versões do Ruby comuns, até e incluindo a 3.02. Para saber mais, confira o "Log de alterações do GitHub".

Foram feitas inúmeras melhorias na API do code scanning:

• O carimbo de data/hora do fixed_at foi adicionado aos alertas. Esse carimbo de data/hora é o primeiro momento que o alerta não foi detectado em uma análise.
• Os resultados do alerta agora podem ser classificados usando sort e direction em created, updated ou number. Para saber mais, confira "Listar os alertas da verificação de código de um repositório".
• Um cabeçalho Last-Modified foi adicionado aos alertas e à resposta do ponto de extremidade de alerta. Para saber mais, confira Last-Modified na documentação do Mozilla.
• O campo relatedLocations foi adicionado à resposta SARIF ao solicitar uma análise de verificação de código. O campo pode conter localizações que não são a localização primária do alerta. Confira um exemplo na especificação SARIF e saiba mais em "Realizar uma análise de verificação de código em um repositório".
• Os dados de help e de tags foram adicionados ao objeto de regra de alerta de resposta do webhook. Para saber mais, confira "Eventos e conteúdos de webhooks de alerta de verificação de código".
• Os tokens de acesso pessoal com o escopo public_repo agora têm acesso de gravação para pontos de extremidade de verificação de código em repositórios públicos, caso o usuário tenha permissão.

Para saber mais, confira "Verificação de código" na documentação da API REST.

Os clientes do GitHub Advanced Security agora podem usar a API REST para recuperar resultados de verificação de segredo do repositório privado no nível da empresa. Os novos pontos de extremidade complementam os pontos de extremidade existentes do nível de repositório e do nível da organização. Para saber mais, confira "Verificação de segredo" na documentação da API REST.

O suporte ao GitHub Mobile agora está habilitado por padrão para novas instâncias do GitHub Enterprise Server. Se você não tiver desabilitado ou habilitado explicitamente o GitHub Mobile, o GitHub Mobile será habilitado quando você atualizar para o GitHub Enterprise Server 3.4.0 ou posterior. Se você desabilitar ou habilitar o GitHub Mobile na sua instância, sua preferência será preservada após o upgrade. Para saber mais, confira "Gerenciar o GitHub Mobile para sua empresa".

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 específicos do processamento de ganchos pré-recebimento podem causar falha em alguns ganchos 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.

Depois de registrar um executor auto-hospedado com o parâmetro --ephemeral em mais de um nível (por exemplo, tanto no nível de empresa quanto no de organização), ele pode ficar preso em um estado ocioso e precisar de um novo registro. [Atualizado em: 17-06-2022]

Ao usar declarações criptografadas SAML com o GitHub Enterprise Server 3.4.0 e 3.4.1, um novo atributo XML WantAssertionsEncrypted no SPSSODescriptor contém um atributo inválido para metadados SAML. Os IdPs que consomem esse ponto de extremidade de metadados SAML podem encontrar erros ao validar o esquema XML de metadados SAML. Uma correção estará disponível na próxima versão de patch. [Atualizado em: 11-04-2022]

Para solucionar esse problema, é possível executar uma das ações a seguir.

• Reconfigure o IdP carregando uma cópia estática dos metadados SAML sem o atributo WantAssertionsEncrypted.
• Copie os metadados SAML, remova o atributo WantAssertionsEncrypted, hospede-o em um servidor Web e reconfigure o IdP para apontar para a URL.

Em alguns casos, os clientes do GitHub Advanced Security que fizerem upgrade para o GitHub Enterprise Server 3.5 ou posterior poderão perceber que os alertas da verificação secreta 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 de uma versão anterior para a versão 3.5 ou posterior. Uma correção está disponível nas versões de patch 3.5.5 e 3.6.1.

Para planejar uma atualização até a versão 3.4, confira o Assistente de atualização. [Atualizado em: 09/01/2022]

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

O GitHub Enterprise Server 3.0 foi descontinuado em 16 de fevereiro de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

O GitHub Enterprise Server 3.1 será descontinuado em 3 de junho de 2022. Isso significa que nenhum lançamento de patch será feito, mesmo para questões críticas de segurança, após esta data. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a versão mais recente do GitHub Enterprise Server assim que possível.

Começando em GitHub Enterprise Server 3.3, GitHub Enterprise Server no XenServer foi preterido e não é mais compatível. Entre em contato com o Suporte do GitHub em caso de dúvidas ou preocupações.

Devido ao baixo uso, preterimos a versão prévia da API de Referências de Conteúdo em GitHub Enterprise Server 3.4. A API era acessível anteriormente com o cabeçalho corsair-preview. Os usuários podem continuar a navegar para URLs externas com esta API. Qualquer uso registrado da API de Referências de Conteúdo não receberá mais uma notificação de Webhook para URLs dos seus domínios registrados e não retornamos mais códigos de resposta válidos para tentativas de atualizações para anexações de conteúdo existente.

A versão prévia da API de Códigos de Conduta, que era acessível com o cabeçalho scarlet-witch-preview, foi preterida e não está mais acessível no GitHub Enterprise Server 3.4. Como alternativa, é recomendado usar o ponto de extremidade "Obter métricas de perfil da comunidade" para recuperar informações sobre o código de conduta de um repositório. Para saber mais, confira o "Aviso de substituição: versão prévia da API de Códigos de Conduta" no log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.4, a versão preterida dos pontos de extremidade da API de Aplicativo OAuth foi removida. Se você encontrar mensagens de erro 404 nesses pontos de extremidade, converta o código para as versões da API de Aplicativo OAuth que não possuem access_tokens na URL. Também desabilitamos o uso de autenticação de API usando os parâmetros de consulta. Como alternativa, é recomendado usar a autenticação da API no cabeçalho da solicitação.

O executor CodeQL é preterido em GitHub Enterprise Server 3.4 e não é mais compatível. O preterimento somente afeta usuários que usam a verificação de código de CodeQL em sistemas CI/CD de terceiros; os usuários de GitHub Actions não são afetados. Recomendamos que os clientes migrem para a CLI CodeQL, que é uma substituição de recurso completo para o executor CodeQL. Para saber mais, confira o "Log de alterações do GitHub.

Desde o GitHub Enterprise Server 3.1, o suporte a extensões de bit-cache do proprietário do GitHub começou a ser substituído. Essas extensões foram preteridas a partir do GitHub Enterprise Server 3.3.

Quaisquer repositórios presentes e ativos no sua instância do GitHub Enterprise Server que executavam a versão 3.1 ou 3.2 terão sido atualizados automaticamente.

Repositórios que não estavam presentes e ativos antes de atualizar para GitHub Enterprise Server 3.3 podem não desempenhar de modo otimizado até que a tarefa de manutenção de repositório tenha sido executada e concluída com sucesso.

Para iniciar uma tarefa de manutenção de repositório manualmente, acesse https://<hostname>/stafftools/repositories/<owner>/<repository>/network em cada repositório afetado e clique no botão “Agendar”.

Após 3 de junho, o GitHub Connect não funcionará mais nas instâncias que executam o GitHub Enterprise Server 3.1 ou versões anteriores devido à alteração no formato dos tokens de autenticação do GitHub. Para saber mais, confira o Log de alterações do GitHub. [Atualizado em: 14-06-2022]