Enterprise Server 3.3 release notes

MEDIUM: Prevents an attack where a server-side request forgery (SSRF) could potentially force the Subversion (SVN) bridge to execute remote code by injecting arbitrary data into Memcached.

MEDIUM: Prevents an attacker from executing Javascript code by exploiting a cross-site scripting (XSS) vulnerability in dropdown UI elements within the GitHub Enterprise Server web interface.

Updates Grafana to version 7.5.16, which addresses various security vulnerabilities including CVE-2020-13379 and CVE-2022-21702.

Packages have been updated to the latest security versions.

Fixed an issue where the files inside the artifact zip archives had permissions of 000 when unpacked using an unzip tool. Now the files will have the permissions set to 644, the same way as it works in GitHub.com.

In some cases, the collectd daemon could consume excess memory.

In some cases, backups of rotated log files could accumulate and consume excess storage.

After an upgrade to a new feature release and subsequent configuration run, Elasticsearch could log excessive exceptions while rebuilding indices.

In some cases where a protected branch required more than one approving review, a pull request could be merged with fewer than the required number of approving reviews.

On instances using LDAP authentication, the authentication prompt for sudo mode incorrectly placed the cursor within the password field by default when text fields for both a username and password were visible.

MÉDIO: Garante que o github.company.com e github-company.com não sejam avaliados por serviços internos como nomes de host idênticos, impedindo um potencial ataque de segurança do lado do servidor (SSRF).

LOW: An attacker could access the Management Console with a path traversal attack via HTTP even if external firewall rules blocked HTTP access.

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

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

Depois de fazer o merge de um branch no branch padrão, o link "Histórico" para um arquivo ainda seria um link para o branch anterior ao invés do branch de destino.

A criação ou atualização das execuções de verificação ou conjuntos de verificações pode retornar 500 Internal Server Error se o valor para certos campos, assim como o nome, fosse muito longo.

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

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

Nas configurações HA em que o nome de host do nó primário era maior que 60 caracteres, o MySQL falharia ao ser configurado

O argumento "--gateway" foi adicionado ao comando "ghe-setup-network", para permitir passar o endereço de gateway ao definir as configurações da rede usando a linha de comando.

Os anexos de imagem que foram excluídos retornariam um 500 Internal Server Error em vez de 404 Not Found.

O cálculo de "máximo de committers em toda a instância" relatado no painel de administração do site estava incorreto.

Uma entrada de banco de dados incorreta para réplicas do repositório causou erros de banco de dados ao executar uma restauração usando GitHub Enterprise Server Backup Utilities.

Otimizou a inclusão de métricas ao gerar um pacote de suporte para cluster.

Nas configurações AH em que Elasticsearch relatou um status amarelo válido, as alterações introduzidas em uma correção anterior bloqueariam o comando ghe-repl-stop e não permitiriam que a replicação fosse interrompida. Usando ghe-repo-stop --force agora forçará o Elasticsearch a parar quando o serviço estiver em um status amarelo normal ou válido.

Ao usar ghe-migrator ou exportar de GitHub.com, as migrações falhariam ao exportar anexos de pull request.

MÉDIO: Identificou-se um problema de segurança no resolvedor do nginx, em que um invasor que poderia forjar pacotes UDP do servidor DNS pode fazer com que a memória de 1 byte seja sobrescrita, resultando em falhas no processo dos trabalhadores ou outros impactos potencialmente prejudiciais. A vulnerabilidade foi atribuída CVE-2021-23017.

Atualizadou as ações actions/checkout@v2 e actions/checkout@v3 para endereçar novas vulnerabilidades anunciadas na [postagem do blogue de aplicação de segurança do Git](https://github.blog/2022-04-12-git-security-vulnerability-announced ced/).

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

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

O SNMP registrou incorretamente um número alto de mensagens de erro Cannot statfs para o syslog

Para instâncias configuradas com a autenticação SAML e o recurso interno habilitado, usuários integrados ficariam presos em um loop de "login" ao tentar efetuar o login a partir da página gerada após o logout.

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

Ao usar declarações criptografadas do SAML, algumas afirmações não estavam marcando corretamente chaves SSH como verificada.

Vídeos enviados para comentários de problemas não seriam interpretados corretamente.

Ao usar o gerenciador de arquivos na página de um repositório, digitar a tecla backspace dentro do campo de pesquisa geraria resultados de pesquisa listados várias vezes e causaria problemas de interpretação.

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

Ao usar ghe-migrator, uma migração falharia na importação de anexos do arquivo de vídeo em problemas e pull requests.

The Releases page would return a 500 error when the repository has tags that contain non-ASCII characters. [Updated: 2022-06-10]

Nas configurações de alta disponibilidade, explique que a página de visão geral de replicação no Console de Gerenciamento exibe somente a configuração de replicação atual, não o status de replicação atual.

Ao habilitar GitHub Package Registry, explique que o uso de um token de Assinatura de Acesso Compartilhado (SAS) como string de conexão não é compatível atualmente.

Pacotes de suporte agora incluem a contagem de linhas armazenadas no MySQL.

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

O campo de resposta run_started_at agora está incluído no Fluxo de trabalho executa a API e na carga do evento workflow_run.

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

Quando um arquivo de manifesto foi excluído de um repositório, o manifesto não seria removido da página "Gráfico de dependência" do repositório.

Resolvida uma regressão que poderia levar a falhas consistentes para recuperar artefatos e fazer o download dos arquivos de log para GitHub Actions. Em algumas circunstâncias, paramos de resolver URLs para comunicações internas que usavam localhost e em vez disso usavam incorretamente o nome do host da instância.

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

Arquivos de log rotacionados com o .backup da extensão seriam acumulados em diretórios que contêm logs de sistema.

Em algumas topologias de cluster, os utilitários de linha de comando 'ghe-spokesctl' e 'ghe-btop' falharam em executar.

Os índices de pesquisa do Elasticsearch podem ser duplicados durante uma atualização do pacote, devido a um serviço elasticsearch-upgrade em execução várias vezes em paralelo.

Nas visualizações de pull request e de commit, os diffs avançados falhariam em carregar alguns arquivos rastreados pelo LFS do Git.

Ao converter a conta de um usuário em uma organização, se a conta de usuário era proprietáris da conta corporativa de GitHub Enterprise Server, a organização convertida apareceria incorretamente na lista de proprietários da empresa.

Criar um token OAuth de representação usando a API REST da Administração Enterprise resultou em um erro quando uma integração que corresponde ao ID do Aplicativo OAuth já existia.

A API REST de digitalização de segredo retornaria um código de resposta 500 se houvesse UTF8 caracteres presentes em um segredo detectado.

Os servidores de cache do repositório podem servir dados de locais que não são do cache mesmo quando os dados estavam disponíveis no local do cache local.

Os erros de configuração que interrompem a execução de uma configuração aplicada agora são retornados para o terminal, além do log de configuração.

Ao tentar armazenar em cache um valor maior que o máximo permitido no Memcached, ocorreu um erro, porém a chave não foi relatada.

Se as funcionalidades de Segurança Avançada GitHub estiverem habilitadas na sua instância, o desempenho de trabalhos em segundo plano melhorou ao processar lotes para contribuições no repositório.

MÉDIO: Uma vulnerabilidade de travessia de caminho foi identificada em GitHub Enterprise Server Console de Gerenciamento que permitiu ignorar as proteções do CSRF. Esta vulnerabilidade afetou todas as versões de GitHub Enterprise Server antes anteriores à 3.5 e foi corrigida nas versões 3.1.19, 3.2.11, 3.3.6, 3.4.1. Essa vulnerabilidade foi reportada através do programa de compensação de erros de GitHub e recebeu o CVE-2022-23732.

MÉDIO: Foi identificada uma vulnerabilidade de sobrefluxo no branch 1.x e no branch 2.x do yajil, que leva à subsequente corrupção de memória heap ao lidar com entradas grandes (~2 GB). Esta vulnerabilidade foi relatada internamente e recebeu o CVE-2022-24795.

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

Ao habilitar Dependabot, um erro fez com que algumas consultorias de segurança fossem lidas temporariamente como não aplicáveis.

os processos do Minio teriam alto uso de CPU se uma opção antiga de configuração estivesse presente após a atualização de GitHub Enterprise Server.

As opções para habilitar TLS 1.0 e TLS 1. nas configurações de privacidade do Console de Gerenciamento foram mostradas, embora a remoção dessas versões de protocolo tenha ocorrido em uma versão anterior.

Em um ambiente HA, a configuração da replicação do MSSQL pode exigir etapas manuais adicionais depois de habilitar GitHub Actions pela primeira vez.

Um subconjunto de arquivos de configuração interna são atualizados de forma mais confiável após um hotpatch.

O script ghe-run-migrations às vezes falha ao gerar nomes de certificados temporários corretamente.

Em um ambiente de cluster, as operações de FLS do Git podem falhar com chamadas de API interna com falhas que cruzaram vários nós web.

Os hooks pre-receive que usavam gpg --import venceram devido a privilégios insuficientes de syscall.

Em algumas topologias de cluster, as informações de entrega de webhook não estavam disponíveis.

As verificações de integridade do Elasticsearch não permitiriam um estado de cçister amarelo ao realizar migrações.

Os repositórios exibiriam uma guia de discussões não funcionais na interface de usuário da web.

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

Os links para páginas inacessíveis foram removidos.

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

Algumas instâncias experimentaram um alto uso da CPU devido a grandes quantidades de trabalhos desnecessários em segundo plano que estão sendo enfileirados.

Os trabalhos de sincronização do usuário LDAP falhariam ao tentar sincronizar as chaves GPG que haviam sido sincronizadas anteriormente.

Seguir um link para uma pull request do painel de pull request dos usuários faria com que o header do repositório não fosse carregado.

Adicionar uma equipe como revisora a um pull request às vezes poderia mostrar o número incorreto de integrantes dessa equipe.

O ponto de extremidade da API de associação da equipe de remoção responderia com um erro ao tentar remover um integrante gerenciado externamente através de um grupo do SCIM.

Um grande número de usuários inativos pode causar falha na configuração de GitHub Connect.

A página "Cadastros e recursos betaa" na interface de administração do site estava disponível de forma incorreta.

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

O comando spokesctl cache-policy rm não falha mais com a mensagem error: failed to delete cache policy.

Os limites de conexão Memcached foram aumentados para melhor acomodar as topologias de grandes clusters.

A API do Gráfico de Dependência correu anteriormente com uma porta definida estaticamente.

As contagens de fragmentos padrão para fragmentos do Elasticsearch relacionados ao clusters foram atualizadas.

Ao filtrar os integrantes da empresa pela função da organização na página "Pessoas", o texto dos itens do menu suspenso foi melhorado.

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

O desempenho foi melhorado para solicitações da web feitas por proprietários das empresas.

ALTO: Uma vulnerabilidade de sobrefluxo de inteiros foi identificada no analisador do markdown do GitHub que poderia potencialmente levar a vazamentos de informações e a RCE. Essa vulnerabilidade foi relatada através do programa de compensação de erros do GitHub por Felix Wilhelm do Projeto Zero do Google, e foi atribuída ao CVE-2022-24724.

As atualizações às vezes poderiam falhar se o relógio da réplica de alta disponibilidade estivesse fora de sincronia com o primário.

Aplicativos OAuth criados após 1 de setembro, 2020 não puderam de usar o Ponto de extremidade API do Check-Authorization.

Foi possível para um usuário registrar um usuário ou organização denominado "saml".

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

As configurações de armazenamento de pacotes do GitHub não puderam ser validadas e salvas no Console de Gerenciamento quando o Azure Blob Storage foi usado.

A opção de configuração mssql.backup.cadence falhou no ghe-config-check com um alerta de conjunto de caracteres inválido.

Corrige SystemStackError (stack muito profundo) ao obter mais de 2^{^16} chaves de memcached.

Vários menus de seleção do site foram interpretados incorretamente e não funcionaram.

Gráfico de Dependência agora pode ser habilitado sem dados de vulnerabilidade, permitindo que os clientes vejam quais dependências estão em uso e em que versões. Habilitar o Gráfico de Dependência sem habilitar o GitHub Connect não fornecerá informações de vulnerabilidade.

A verificação de segredo ignora a verificação ZIP e outros arquivos para segredos.

MÉDIO: As chamadas de API de digitalização de segredo podem retornar alertas para repositórios fora do escopo da solicitação.

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

O Pages ficaria indisponível após uma rotação do segredo do MySQL até nginx ser reiniciado manualmente.

As migrações podem falhar quando GitHub Actions foi habilitado.

Ao definir a agenda de manutenção com uma data da ISO 8601, o horário programado real não corresponderá devido fato de o fuso horário não ser convertido em UTC.

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

O número da versão não poderia ser atualizado corretamente após a instalação de um hotpatch que usa ghe-cluster-each.

Trabalhos de limpeza na tabela de webhook podem ser executados simultaneamente, causando contenção de recursos e aumentando o tempo de execução do trabalho.

Quando executado no primário, o ghe-repl-teardown em uma réplica não remove a réplica do grupo de disponibilidade do MSSQL.

A capacidade de limitar notificações com base em e-mail para usuários com e-mails em um domínio verificado ou aprovado não funcionou corretamente.

Ao usar a autenticação CAS e a opção "Reativar usuários suspensos" foi habilitada, os usuários suspensos não foram reativados automaticamente.

Uma migração de execução longa do banco de dados relacionada às configurações de alerta de segurança pode atrasar a conclusão da atualização.

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.

Os pacotes foram atualizados para as últimas versões de segurança. Nestas atualizações, o Log4j foi atualizado para a versão 2.17.1. Observação: as mitigações anteriores lançadas em 3.3.1, 3.2.6, 3.1.14 e 3.0.22 são suficientes para resolver o impacto do CVE-2021-44228, do CVE-2021-45046, do CVE-2021-45105 e do CVE-2021-44832 nestas versões do GitHub Enterprise Server.

Higienize mais segredos nos pacotes de suporte gerados

Os usuários de equipes com o função de gerente de segurança agora serão notificados dos alertas de segurança em repositórios que estão inspecionando.

O componente gerente de segurança mostrará um aviso menos agressivo quando o número máximo de equipes for alcançado.

A página de gerenciamento do repositório deve retornar 403 ao tentar remover uma equipe do gerente de segurança do repositório.

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

Os executores auto-hospedados das ações falhariam ao realizar a própria atualização ou executar novos trabalhos após a atualização a partir de uma instalação antiga do GHES.

Não foi possível validar as configurações de armazenamento quando configurar o MinIO como armazenamento blob para pacotes do GitHub.

Não foi possível validar e salvar as configurações de armazenamento do GitHub Actions no Console de Gerenciamento quando o "Estilo de Caminho de Forma" foi selecionado.

As ações seriam deixadas em um estado parado após uma atualização com o modo de manutenção definido.

Às vezes pode ocorrer uma falha ao executar ghe-config-apply devido a problemas de permissão em /data/user/tmp/pages.

O botão salvar no console de gerenciamento não era acessível usando a barra de rolagem nos navegadores de baixa resolução.

Gráficos de monitoramento de tráfego de armazenamento e IOPS e não foram atualizados após a atualização de versão do collectd.

Alguns trabalhos relacionados ao webhook poderiam gerar uma grande quantidade de registros.

Um item de navegação de cobrança estava visível nas páginas de administrador do site.

Vários links de documentação geraram um erro 404 Not Found error.

Crítico: A vulnerabilidade da execução de um código remoto na biblioteca Log4j, identificada como CVE-2021-44228 afetou todas as versões de GitHub Enterprise Server anteriores a 3.3.1. A biblioteca Log4j é usada comom um serviço de código aberto em execução na instância de GitHub Enterprise Server. Essa vulnerabilidade foi corrigida nas versões GitHub Enterprise Server 3.0.22, 3.1.14, 3.2.6 e 3.3.1. Para obter mais informações, consulte essa postagem no blogue do GitHub.

Atualização de 17 de dezembro de 2021: As correções em vigor para esta versão também mitigam o [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename. gi?name=CVE-2021-45046), que foi publicado após esta versão. Nenhuma atualização adicional para GitHub Enterprise Server é necessária para mitigar CVE-2021-44228 e CVE-2021-45046.

Os proprietários da organização agora podem conceder às equipes o acesso para gerenciar alertas de segurança e configurações de seus repositórios. A função "gerente de segurança" pode ser aplicada a qualquer equipe e concede aos integrantes da equipe o seguinte acesso:

• Acesso de leitura em todos os repositórios da organização.
• Acesso de gravação em todos os alertas de segurança na organização.
• Acesso na aba de segurança a nível da organização.
• Acesso de gravação nas configurações de segurança no nível da organização.
• Acesso de gravação nas configurações de segurança no nível de repositório.

Para obter mais informações, consulte "Gerenciando gerentes de segurança na sua organização."

GitHub Actions agora é compatível com executores efêmeros (um único trabalho) auto-hospedados e um novo workflow_job webhook para facilitar o dimensionamento automático dos executores.

Os executores efêmeros são bons para ambientes gerenciados de forma automática, em que cada trabalho deve ser executado em uma imagem limpa. Depois que um trabalho é executado, os executores efêmeros têm os seus registros automaticamente cancelados de your GitHub Enterprise Server instance, permitindo que você execute qualquer gerenciamento de pós-trabalho.

Você pode combinar executores efêmeros com o novo webhook workflow_job para dimensionar automaticamente executores auto-hospedados em resposta a solicitações de trabalho de GitHub Actions.

Para obter mais informações, consulte "[Redimensionamento automático com executoresauto-hospedados](/actions/hosting-your-own runners/autoscaling-with-autohosted-runners)" e "eventos e cargas."

Um tema de alto contraste escuro, com maior contraste entre o primeiro e os elementos de segundo plano, está disponível em GitHub Enterprise Server 3.3. Esta versão também inclui melhorias para o sistema de cores de todos os temas de GitHub .


Para mais informações sobre a mudança de tema, consulte "Gerenciando suas configurações de tema."

GitHub Enterprise Server 3.3 inclui melhorias na manutenção dos repositórios, especialmente para repositórios que contêm muitos objetos inacessíveis. Observe que o primeiro ciclo de manutenção após a atualização para GitHub Enterprise Server 3.3 pode levar mais tempo do que o normal para ser concluído.

GitHub Enterprise Server 3.3 inclui o beta público do cache de repositórios para equipes e infraestruturas de CI distribuídas geograficamente. O cache do repositório mantém uma cópia somente leitura de seus repositórios disponíveis em outras localidades, o que impede os clientes de fazer o download do conteúdo do Git duplicado a partir da sua instância principal. Para obter mais informações, consulte "Sobre cache do repositório."

GitHub Enterprise Server 3.3 inclui melhorias no processo de representação do usuário. Uma sessão de representação agora requer uma justificação para a representação. As ações são registradas no log de auditoria como sendo realizadas como um usuário representado e o usuário que for representado receberá uma notificação por e-mail de que ele foi representado por um administrador da empresa. Para obter mais informações, consulte "Personificando um usuário."

Um novo serviço de processamento de transmissão foi adicionado para facilitar o crescimento do conjunto de eventos publicados no log de auditoria, incluindo eventos associados à atividade do Git e GitHub Actions.

O registro de conexão de dados GitHub Connect agora inclui uma lista de funcionalidades de GitHub Connect habilitadas. [Atualizado em 2021-12-09]

Uma data de vencimento agora pode ser definida para tokens de acesso pessoais novos e existentes. É altamente recomendado definir uma data de expiração em tokens de acesso pessoal para evitar que tokens antigos vazem e comprometam a segurança. Os proprietários de tokens receberão um e-mail quando for hora de renovar um token que está prestes a vencer. Os tokens vencidos podem ser regenerados, dando aos usuários um token duplicado com as mesmas propriedades do original.

Ao usar um token de acesso pessoal com a API de GitHub um novo cabeçalho GitHub-Authentication-Token-Expiration será incluído na resposta, que indica a data de validade do token. Para obter mais informações, consulte "Criando um token de acesso pessoal."

Os e-mails de notificação das discussões agora incluem (Discussion #xx) no assunto, para que você possa reconhecer e filtrar e-mails que fazem referências a discussões.

Repositórios públicos agora têm uma etiqueta Público ao lado de nomes como repositórios privados e internos. Esta alteração torna mais fácil a identificação de repositórios públicos e evita a confirmação acidental de código privado.

Se você especificar o nome exato de um branch ao usar o menu seletor do branch, o resultado agora será exibido na parte superior da lista de branches correspondentes. Anteriormente, as correspondências exatas de nomes de branch poderiam aparecer na parte inferior da lista.

Ao visualizar um branch com um pull request aberto correspondente, GitHub Enterprise Server agora irá vincular diretamente ao pull request. Anteriormente, haveria uma instrução para contribuir usando a comparação do branch ou para abrir um novo pull request.

Agora você pode clicar em um botão para copiar todo o conteúdo sem ser processado de um arquivo para a área de transferência. Anteriormente, você deveria abrir o arquivo sem processamento, selecionar todos e, em seguida, copiar. Para copiar o conteúdo de um arquivo, acesse o arquivo e clique em na barra de ferramentas. Observe que este recurso está disponível apenas em alguns navegadores.

Ao criar uma nova versão, agora você pode selecionar ou criar a tag usando um seletor suspenso, ao invés de especificar a tag em um campo de texto. Para obter mais informações, consulte "Gerenciar versões em um repositório".

Um aviso agora é exibido ao visualizar um arquivo que contém texto bidirecional do Unicode. O texto bidirecional Unicode pode ser interpretado ou compilado de forma diferente da que aparece na interface do usuário. Por exemplo, caracteres bidirecionais ocultos Unicode podem ser usados para trocar segmentos de texto em um arquivo. Para obter mais informações sobre a substituição desses caracteres, consulte o registro de alterações de GitHub.

Agora você pode usar arquivos "CITATION.cff" para que os outros saibam como você gostaria que eles citassem seu trabalho. Os arquivos "CITATION.cff" são arquivos de texto simples com informações de citação legíveis por pessoas e máquinas. GitHub Enterprise Server analisa essa informação em formatos de citação comuns como [APA](https://apastyle. pa.org) e BibTeX. Para obter mais informações, consulte "Sobre arquivos de CITATION."

Você pode usar novos atalhos de teclado para aspas e listas em arquivos Markdown, problemas, pull requests e comentários.

• Para adicionar citações, use cmd shift 7 no Mac ou ctrl shift . no Windows e Linux.
• Para adicionar uma lista ordenada, use cmd shift 7 no Mac ou ctrl shift 7 no Windows e Linux.
• Para adicionar uma lista não ordenada, use cmd shift 8 em Mac ou ctrl shift 8 no Windows e no Linux.

Consulte "Atalhos de teclado" para obter uma lista completa dos atalhos disponíveis.

Agora você pode usar sintaxe do nota de rodapé em qualquer campo do Markdown. As notas de rodapé são exibidas como links sobrescritos em que você pode clicar para pular para a informação referenciada, que é exibida em uma nova seção no final do documento. Para obter mais informações sobre a sintaxe, consulte "Sintaxe de escrita básica."

Ao visualizar arquivos de Markdown, agora você pode clicar em na barra de ferramentas para ver a fonte de arquivo de Markdown. Anteriormente, você deveria usar a visão culpada para vincular a números de linha específicos na fonte de um arquivo de Markdown.

Agora você pode adicionar imagens e vídeos aos arquivos Markdown nos gists, colando-os no corpo do Markdown ou selecionando-os da caixa de diálogo na parte inferior do arquivo Markdown. Para obter informações sobre tipos de arquivos compatíveis, consulte "Anexando arquivos."

GitHub Enterprise Server agora gera automaticamente uma tabela de conteúdo para Wikis com base nos cabeçalhos.

Ao arrastar e soltar arquivos para um editor de Markdown, como imagens e vídeos, GitHub Enterprise Server agora usa o local do ponteiro do mouse em vez do local do cursor ao colocar o arquivo.

Agora você pode pesquisar problemas por etiqueta usando um operador lógico OU. Para filtrar os problemas usando o OU lógico, use a sintaxe de vírgula. Por exemplo, label:"good first issue","bug" irá listar todos os problemas com a etiqueta good first issue ou bug. Para obter mais informações, consulte "Filtrar e pesquisar problemas e pull requests."

Foram realizadas melhorias para ajudar as equipes a gerenciar as atividades de revisão de código. Agora você pode:

• Limitar atribuição apenas aos integrantes diretos da equipe.
• Continuar com a atribuição automática, mesmo que um ou mais integrantes da equipe já estejam solicitados.
• Manter uma equipe atribuída para revisar, mesmo que um ou mais integrantes sejam recém-designados.

A barra lateral da linha do tempo e revisores na página de pull request agora indica se uma solicitação de revisão foi automaticamente atribuída a um ou mais integrantes da equipe.

Para obter mais informações, consulte o registro de alterações de GitHub.

Agora você pode filtrar pesquisas de pull request para incluir apenas pull requests que solicitaram que você revise diretamente.

Os arquivos filtrados em pull requests agora estão completamente ocultos na visualização e não são mais exibidos como recolhidos na guia "Arquivos alterados". O menu "Filtro de Arquivo" também foi simplificado. Para obter mais informações, consulte "Filtrar arquivos em um pull request."

Agora você pode criar "ações compostas" que combinam várias etapas do fluxo de trabalho em uma ação, e inclui a capacidade de fazer referência a outras ações. Isto facilita a redução da duplicação de fluxos de trabalho. Anteriormente, uma ação só podia usar scripts na definição do seu YAML. Para obter mais informações, consulte "Criar uma ação composta."

O gerenciamento de executores auto-hospedados no nível corporativo não exige mais o uso de tokens de acesso pessoal com o escopo "admin:enterprise". Em vez disso, você pode usar o novo escopo "manage_runners:enterprise" para restringir as permissões nos seus tokens. Os tokens com este escopo podem efetuar a autenticação em muitos pontos da API REST para gerenciar os runners auto-hospedados de sua empresa.

O log de auditoria agora inclui eventos adicionais para GitHub Actions. As entradas de log de auditoria agora estão registradas nos seguintes eventos:

• Um executor auto-hospedado está registrado ou removido.
• Um executor auto-hospedado é adicionado a um grupo de executores ou removido de um grupo de executores.
• Um grupo de executores foi criado ou removido.
• A execução de um fluxo de trabalho foi criada ou concluída.
• Uma tarefa de fluxo de trabalho está preparada. Importante: Este log inclui a lista de segredos que foram fornecidos ao executor.

Para obter mais informações, consulte "Aumentando a segurança para GitHub Actions."

GitHub Enterprise Server 3.3 contém melhorias de desempenho para a simultaneidade de trabalho com GitHub Actions. Para mais informações sobre os novos objetivos de desempenho em uma variedade de configurações de CPU e memória, consulte "Primeiros passos com GitHub Actions para GitHub Enterprise Server."

Para mitigar as pessoas com informações privilegiadas nos ataques de intermediários ao usar ações resolvidas por meio de GitHub Connect para GitHub.com de GitHub Enterprise Server, o namespace das ações (proprietário/nome) é desativado ao usar. A remoção do namespace impede que esse namespace seja criado na sua instância de GitHub Enterprise Server e garante que todos os fluxos de trabalho referenciados pela ação o farão o download de GitHub.com.

Quando um repositório é excluído, todos os arquivos de pacote associados são imediatamente excluídos do seu armazenamento externo de GitHub Package Registry.

A revisão de dependências está fora de versão beta e agora está geralmente disponível para clientes de Segurança Avançada GitHub. A revisão de dependências fornece uma visão de fácil compreensão das alterações da dependências e seu impacto em segurança na guia "Arquivos alterados" dos pull requests. Ele informa quais dependências foram adicionadas, removidas ou atualizadas, junto com informações sobre vulnerabilidade. Para obter mais informações, consulte "Revisando alterações de dependências em um pull request."

Dependabot agora está disponível como uma versão privada, oferecendo atualizações de versão e segurança para vários ecossistemas populares. Dependabot em GitHub Enterprise Server exige GitHub Actions e um pool de executores auto-hospedados configurados para uso de Dependabot. Dependabot em GitHub Enterprise Server também exige que GitHub Connect esteja habilitado. Para saber mais e se inscrever para a versão beta, entre em contato com a equipe de vendas do GitHub.

A profundidade da análise de CodeQLfoi melhorada adicionando suporte a mais [bibliotecas e estruturas](https://codeql.github. om/docs/codeql-overview/supported-languages-and-frameworks/) e aumentando a cobertura da nossa biblioteca e modelos de estruturas existentes. A análise do JavaScript é compatível com a maioria das linguagens de modelo comuns e [Java](https://github. agora/github/codeql/tree/main/java) abrange mais de três vezes os pontos de extremidade das versões anteriores CodeQL. Como resultado, CodeQL pode detectar ainda mais fontes potenciais de dados de usuário não confiáveis, passos por meio dos quais esses dados fluem e os possíveis consumidores onde os dados podem terminar. Isto resulta numa melhoria global da qualidade dos alertas de Varredura de código.

CodeQL agora é compatível com a verificação de funcionalidades da linguagem padrão no Java 16, como registros e correspondência de padrões. CodeQL é pode de analisar o código escrito nas versões 7 a 16 do Java. Para obter mais informações sobre linguagens e estruturas compatíveis, consulte a documentação de CodeQL.

Foram feitas melhorias no acionamento 'on:push' de Varredura de código quando o código é rnviafo por push para um pull request. Se uma digitalização 'on:push' retornar os resultados associados a um pull request, Varredura de código agora mostrará esses alertas no pull request.

Alguns outros sistemas de CI/CD podem ser configurados exclusivamente para acionar um pipeline quando o código é enviado por push para um branch, ou até exclusivamente para cada commit. Sempre que esse pipeline de análise for acionado e os resultados forem enviados para a API do SARIF, Varredura de código também tentará igualar os resultados da análise a um pull request aberto. Se for encontrado um pull request aberto, os resultados serão publicados conforme descrito acima. Para obter mais informações, consulte o [registro de alterações de GitHub](https://github.blog/changelog/2021-09-27-mostrando-verificação de código-alertas-on-pull-requests/).

Agora você pode usar o novo filtro de pull request na página de alertas de Varredura de código para encontrar todos os alertas de Varredura de código associados a um pull request. Um novo link "Ver todos os alertas do branch" na aba "Verificações" de pull request permite que você veja diretamente os alertas de Varredura de código com o filtro de pull request específico já aplicado. Para obter mais informações, consulte o registro de alteraçõesGitHub .

Os padrões definidos pelo usuário para varredura secreta estão fora da versão beta e agora estão amplamente disponíveis para os clientes de Segurança Avançada GitHub. A outra novidade nesta versão é a habilidade de editar padrões personalizados definidos no repositório, organização e níveis empresariais. Depois de editar e salvar um padrão, varredura secreta pesquisa correspondências em todo o histórico de um repositório Git e em quaisquer novos commits. Editar um padrão irá fechar os alertas associados com o padrão se eles não coincidirem mais com a versão atualizada. Estão previstas outras melhorias como, por exemplo, os testes, são planejados para versões futuras. Para obter mais informações, consulte "Definindo padrões personalizados para digitalização de segredo."

A maioria das pré-visualizações da API REST foram graduadas e agora fazem parte oficial da API. Os cabeçalhos de visualização não são mais necessários para a maioria dos pontos de API REST, mas ainda funcionarão como esperado se você especificar uma pré-visualização graduada no cabeçalho "Aceitar" de uma solicitação. Para pré-visualizações que ainda exigem a especificação da pré-visualização no cabeçalho "Aceitar" de uma solicitação, consulte "Pré-visualizações da API."

Agora você pode usar a API REST para configurar links automáticos personalizados para recursos externos. A API REST agora fornece pontos de extremidade beta GET/POST/DELETE que você pode usar para visualizar, adicionar ou apagar links automáticos personalizados associados a um repositório. Para obter mais informações, consulte "Autolinks."

Agora você pode usar a API REST para sincronizar um repositório bifurcado com o seu repositório upstream. Para obter mais informações, consulte "Branches" na documentação da API REST.

Administradores corporativos do GitHub Enterprise Server agora podem usar a API REST para habilitar ou desabilitar a LFS do Git para um repositório. Para obter mais informações, consulte "Repositories."

Agora você pode usar a API REST para consultar o log de auditoria para uma empresa. Embora o encaminhamento de logs de auditoria ofereçae a capacidade de manter e analisar dados com seu próprio kit de ferramentas e determinar padrões ao longo do tempo, o novo ponto de extremidade pode ajudar você a realizar análises limitadas sobre eventos recentes. Para obter mais informações, consulte "Administração de GitHub Enterprise" na documentação da API REST.

As solicitações da de usuário par servidor do aplicativo GitHub agora podem ler recursos públicos usando a API REST. Isso inclui, por exemplo, a possibilidade de listar os problemas e pull requests de um repositório público e acessar os comentários e conteúdo de um repositório público.

Ao criar ou atualizar um repositório, agora você pode configurar se a bifurcação é permitida usando as APIs REST e do GraphQL. Anteriormente, as APIs para a criação e atualização de repositórios não incluíam os campos "allow_forking" (REST) ou "forkingAllowed" (GraphQL). Para obter mais informações, consulte "Repositories" na documentação da API REST e "Repositories" na documentação da API do GraphQL.

Uma nova mutação do GraphQL createCommitOnBranch torna mais fácil adicionar, atualizar e excluir arquivos no branch de um repositório. Comparado com a API REST, não é necessário criar manualmente blobs e árvores antes de criar o commit. Isso permite que você adicione, atualize ou exclua vários arquivos em uma única chamada de API.

Os commits criados usando a nova API são automaticamente assinados pelo GPG e são [marcados como verificados](/github/authenticating-to-github/managing-commit-signature re-verification/about-commit-subscripre-verification) na interface do usuário de GitHub Enterprise Server. Os aplicativos GitHub podem usar a mutação para criar commits diretamente ou em nome de usuários.

Quando uma nova tag é criada, a carga de webhook push agora inclui um objeto head_commit que contém os dados do commit para o qual a nova tag aponta. Como resultado, o objeto head_commit sempre conterá os dados de commit do commit posterior da carga.

As cargas e tarefas de página agora são significativamente mais rápidas para repositórios com muitas refs do Git.

Após a atualização para GitHub Enterprise Server 3.3, GitHub Actions pode não ser iniciado automaticamente. Para resolver esse problema, conecte-se ao dispositivo via SSH e execute o comando ghe-actions-start.

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.

Arquivos LFS do Git enviados através da interface web são adicionados diretamente ao repositório e de forma incorreta.

Os problemas não podem ser fechados se contiverem um permalink para um blob no mesmo repositório, onde o caminho do arquivo blob's é 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 de GitHub Package Registry não retorna mais o valor de tempo em respostas de metadados. Isso foi feito para permitir melhorias substanciais de desempenho. Continuamos a ter todos os dados necessários para devolver um valor de tempo como parte da resposta aos metadados e retomaremos o retorno desse valor no futuro, assim que tivermos resolvido os problemas de desempenho existentes.

Os limites de recursos que são específicos para processamento de hooks pre-receive podem causar falha em alguns hooks pre-receive.

As configurações de armazenamento de GitHub Actions não podem ser validadas e salvas no Console de gerenciamento quando "Forçar estilo de caminho" for selecionado e deverão ser definidas com a ferramenta de linha de comando ghe-actions-precheck.

GitHub Enterprise Server 3.3 instâncias instaladas no Azure e com mais de 32 núcleos de CPU provisionadas não conseguiriam iniciar, devido a um erro presente no kernel do Linux atual. [Atualizado: 2022-04-08]

GitHub Enterprise Server 2.22 tornou-se obsoleto em 23 de setembro de 2021. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

GitHub Enterprise Server 3.0 irá tornar-se obsoleto em 16 de fevereiro de 2022. Isso significa que não serão feitas versões de patch, mesmo para questões essenciais de segurança, após esta data. Para obter melhor desempenho, melhorar a segurança e novas funcionalidades, faça a atualização para a versão mais recente de GitHub Enterprise Server assim que possível.

Começando com GitHub Enterprise Server 3.3, GitHub Enterprise Server no XenServer está obsoleto e não é mais compatível. Entre em contato com o suporte do GitHub em caso de dúvidas.

Para evitar o registro acidental ou a exposição de access_tokens, não incentivamos o uso de pontos de extremidade da API do aplicativo OAuth e o uso da autenticação da API usando parâmetros de consulta. Veja os seguintes posts para ver as substituições propostas:

• [Substituição da API do aplicativo OAuth](https://developer.github. om/changes/2020-02-14-deprecating-oauth-app-endpoint/#changes-to-make)
• [Substituição da autenticação usando cabeçalhos em vez de parâmetros de consulta](https://developer.github. om/changes/2020-02-10-deprecating-auth-through-query-param/#changes-to-make)

Estes pontos de extremidade e rota de autenticação estão planejados para serem removidos de GitHub Enterprise Server em GitHub Enterprise Server 3.4.

O executor CodeQL está sendo descontinuado. GitHub Enterprise Server 3.3 será a versão final da série que é compatível com o executor de CodeQL. A partir de GitHub Enterprise Server 3.4, o executor de CodeQL será removido e não será mais compatível. A versão 2.6.2 da CLI de CodeQL ou superior é uma substituição completa de recursos para o executor de CodeQL. Para obter mais informações, consulte o registro de alterações de GitHub.

Começando em GitHub Enterprise Server 3.1, o suporte para extensões de bit-cache de GitHub começou a ser eliminado gradualmente. Essas extensões estão agora obsoletas em GitHub Enterprise Server 3.3.

Todos os repositórios que já estavam presentes e ativos na your GitHub Enterprise Server instance versão 3.1 ou 3.2 serão atualizados automaticamente.

Os repositórios que não estavam presentes e ativos antes de atualizar para GitHub Enterprise Server 3.3 podem não ser executados da forma ideal até que uma tarefa de manutenção de repositório seja executada e concluída com sucesso.

Para iniciar uma tarefa de manutenção do repositório manualmente, acesse https:///stafftools/repositórios///network` para cada repositório afetado e clique no botão Cronograma.

O GitHub Connect não funcionará mais após 3 de junho para instâncias executadas no GitHub Enterprise Server 3.1 ou anterior, devido à alteração no formato dos tokens de autenticação do GitHub. Para continuar usando o GitHub Connect, atualize para o GitHub Enterprise Server 3.2 ou superior. Para obter mais informações, consulte o Blogue do GitHub. [Atualizado: 2022-06-14]