Enterprise Server 3.8 release notes

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. GitHub has requested CVE ID CVE-2023-23765 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes.

On an instance with a GitHub Advanced Security license and secret scanning enabled, rotation of the key used to encrypt secrets discovered by secret scanning would fail.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

If a user made a request to the Collaborators API's Add a repository collaborator endpoint specifying a permission of read or write, the instance returned a 500 error.

On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots.

The spokesctl command-line utility accepts more input formats.

People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using ghe-config redis.max-memory-gb VALUE.

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

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

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

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

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

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

Em uma instância com um grande número de organizações, os proprietários da empresa que navegaram até a página de configurações "Segurança e análise" da empresa podem retornar um erro 500.

No GitHub Enterprise Server 3.8 em diante, usar a CLI do Importador do GitHub Enterprise, a startRepositoryMigration API GraphQL ou a API REST "Iniciar uma migração de organização" requer que um provedor de armazenamento de blobs seja configurado no Console de Gerenciamento. Ao usar Armazenamento de Blobs do Azure, os contêineres de armazenamento foram configurados incorretamente para serem acessíveis publicamente. Armazenamento de Blobs do Azure contêineres agora serão configurados para serem privados e introduzimos uma marca que falha explicitamente nas exportações se o contêiner de armazenamento for público.

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

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

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

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

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

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

Em uma instância com uma licença de GitHub Advanced Security em que a verificação de segredo está habilitada, o log excessivo em /var/log pode causar erros voltados para o usuário e degradar o desempenho do sistema se os logs consumissem todo o espaço livre no volume.

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

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

Depois que o administrador do site exporta um arquivo de migração usando o utilitário gh-migrator do GitHub Enterprise Importers, o link para o arquivo permanece acessível por 48 horas em vez de uma hora.

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

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

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

Quando o administrador do site executou ghe-btop por meio do SSH, o comando não foi executado e ocorreu o erro /usr/bin/env: python3: No such file or directory.

Os administradores do site que se prepararam para habilitar o GitHub Actions não puderam executar o utilitário ghe-actions-precheck porque o arquivo de scripts não era executável.

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

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

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

Depois que o administrador do site exportou um arquivo de migração para o AWS S3 usando o utilitário gh-migrator do GitHub Enterprise Importer, a URL do arquivo estava inacessível.

Se o administrador do site exportou um arquivo de migração para o bucket no AWS S3s região us-east-1 usando o utilitário gh-migrator do GitHub Enterprise Importer, o arquivo estava inacessível.

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

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

Depois que o administrador do site exporta um arquivo de migração usando o utilitário gh-migrator do GitHub Enterprise Importer, o link para o arquivo permanece acessível por 48 horas em vez de uma hora.

Em uma instância com uma licença do GitHub Advanced Security, os usuários que criam padrões personalizados para a verificação de segredos podem fornecer expressões que devem ou não corresponder a até dois mil caracteres. Esse limite é um aumento de mil caracteres.

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

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

Em uma instância com o GitHub Actions habilitado, um trabalho de fluxo de trabalho para o GitHub Actions não era iniciado se um grupo de executores correspondente não estivesse disponível quando o trabalho era inicialmente colocado na fila, mesmo que um grupo de executores correspondente ficasse disponível depois que o trabalho entrasse na fila.

Em uma instância com o GitHub Actions habilitado, GitHub Actions já será executado corretamente após a restauração de um repositório excluído.

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

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

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

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

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

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

Os comandos que os administradores do site executaram por meio do SSH em um dos nós de instâncias não eram registrados em /var/log/ssh-console-audit.log.

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

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

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

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

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

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

Quando os usuários pesquisavam gists, o texto no campo de pesquisa não era visível em alguns casos, porque a cor dos textos era idêntica à cor da tela de fundo dos campos.

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

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

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

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

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

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

Em uma instância com uma licença do GitHub Advanced Security, os usuários que criam padrões personalizados para a verificação de segredos podem fornecer expressões que devem ou não corresponder a até dois mil caracteres. Esse limite é um aumento de mil caracteres.

Os projetos, a ferramenta flexível para planejamento e acompanhamento do trabalho no GitHub Enterprise Server, agora estão disponíveis como beta. Um projeto é uma planilha adaptável que se integra aos seus problemas e solicitações de pull para ajudar usuários a planejar e acompanhar o trabalho com eficiência. Os usuários podem criar e personalizar várias exibições, e cada exibição pode filtrar, classificar e agrupar problemas e solicitações de pull. Os usuários também podem definir campos personalizados para acompanhar os metadados exclusivos de uma equipe ou projeto, permitindo a personalização para quaisquer necessidades ou processos. Esse recurso está sujeito a alterações. Para obter mais informações, confira "Sobre Projects (beta)".

Os administradores do site podem aprimorar a segurança de uma instância criando contas de usuário dedicadas para o Console de Gerenciamento. Somente o administrador do site raiz pode criar contas de usuário. Para controlar o acesso das contas de usuário, atribua a função de editor ou operador. Os operadores podem gerenciar o acesso SSH administrativo para a instância. Para mais informações, confira "Gerenciar o acesso ao Console de Gerenciamento".

Para estabelecer ou cumprir as políticas internas, os administradores do site podem usar o Console de Gerenciamento para configurar a política de uma instância para retenção de dados relacionados a verificações, incluindo dados de verificação gerados por GitHub Actions e a API de Status. Os administradores podem habilitar ou desabilitar a retenção, definir um limite de retenção personalizado ou definir um limite de exclusão permanente personalizado. Para obter mais informações, confira "Como configurar aplicativos" [Atualizado em 02-03-2023]

Ao gerar pacotes de suporte usando o utilitário de linha de comando ghe-support-bundle, os administradores do site podem especificar a duração exata a ser usada para coleta de dados no pacote. Para obter mais informações, confira "Utilitários de linha de comando".

Os usuários podem examinar e revogar as sessões do navegador e do GitHub Mobile para uma instância do GitHub Enterprise Server. Para obter mais informações, confira "Como ver e gerenciar suas sessões."

Os proprietários de empresa podem configurar se os administradores do repositório podem habilitar ou desabilitar alertas do Dependabot. Em instâncias com uma licença do GitHub Advanced Security, os proprietários de empresa também podem definir políticas para controlar se os administradores do repositório podem habilitar recursos do GitHub Advanced Security ou a verificação de segredos. Para obter mais informações, confira "Como impor políticas para segurança e análise de código na empresa".

Os proprietários de empresa e organização podem dar suporte à adesão ao princípio de privilégios mínimos, concedendo acesso a pontos de extremidade de log de auditoria sem fornecer privilégios administrativos completos. Para fornecer esse acesso, tokens de acesso pessoal e aplicativos OAuth agora dão suporte ao escopo read:audit_log. Para obter mais informações, confira "Como usar a API do log de auditoria para sua empresa".

Os proprietários de empresa podem detectar e rastrear com mais facilidade a atividade associada a tokens de autenticação exibindo dados de token em eventos de log de auditoria. Para obter mais informações, confira "Como identificar eventos de log de auditoria executados por um token de acesso".

Os proprietários de empresa podem configurar o streaming de log de auditoria para um ponto de extremidade do Datadog. Para obter mais informações, confira "Streaming do log de auditoria para sua empresa".

Os proprietários de empresa em uma instância com uma licença do GitHub Advanced Security podem exibir alterações no GitHub Advanced Security, verificação de segredos e habilitação de proteção por push no log de auditoria. Os proprietários de organização podem exibir alterações em mensagens personalizadas para proteção por push no log de auditoria. Para saber mais, confira a seguinte documentação.

• "business_secret_scanning ações de categoria", "business_secret_scanning_push_protection ações de categoria" e "business_secret_scanning_push_protection_custom_message ações de categoria" em "Eventos de log de auditoria para sua empresa"
• "Como revisar o log de auditoria da sua organização"

Os proprietários corporativos em uma instância com uma licença GitHub Advanced Security podem garantir a conformidade e simplificar a distribuição da verificação de segredos e da proteção por push para todas as organizações na instância usando a API REST. Esse ponto de extremidade complementa a interface do usuário Web existente, bem como os pontos de extremidade existentes para repositórios e organizações. Para obter mais informações, confira "Segurança e análise de código" na documentação da API REST.

Os proprietários de empresa e organização que usam a verificação de segredo em uma instância com uma licença do GitHub Advanced Security podem usar a API REST para especificar um link personalizado a ser exibido quando a proteção por push bloquear um push que contém um segredo. Para obter mais informações, confira "Segurança e análise de código" ou "Organizações" na documentação da API REST.

Os usuários em uma instância com uma licença GitHub Advanced Security que ignoram um alerta de verificação de segredo podem ajudar outros usuários a entender o motivo de o terem ignorado, fornecendo um comentário opcional usando a interface do usuário da Web ou a API REST. Para saber mais, confira a seguinte documentação.

• "Gerenciar alertas da verificação de segredo"
• "Verificação de segredo" na documentação da API REST

Os usuários em uma instância com uma licença do GitHub Advanced Security podem filtrar os resultados da API de Verificação de Código com base na gravidade do alerta nos níveis do repositório ou da organização. Use o parâmetro severity para retornar apenas alertas de verificação de código com uma severidade específica. Para saber mais, confira "Verificação do código" na documentação de API REST.

Os usuários em uma instância com uma licença GitHub Advanced Security podem analisar duas linguagens de programação adicionais em busca de vulnerabilidades e erros usando a verificação de código CodeQL. O suporte para Ruby está em disponibilidade geral, enquanto o suporte para Kotlin está na versão beta e sujeito a alterações.

• A análise do Ruby pode detectar mais do que o dobro do número de CWEs (pontos fracos comuns) que era capaz de detectar durante a versão beta. Um total de 30 regras podem identificar uma série de vulnerabilidades, incluindo XSS (script entre sites), ReDoS (negação de serviço de expressão regular), injeção de SQL e muito mais. A cobertura adicional de biblioteca e estrutura para Ruby-on-Rails garante que os desenvolvedores de serviços Web obtenham resultados ainda mais precisos. O GitHub Enterprise Server dá suporte a todas as versões comuns do Ruby, até e incluindo a 3.1.
• O suporte kotlin é uma extensão do suporte java existente e se beneficia das consultas CodeQL existentes para Java, que se aplicam a aplicativos móveis e aplicativos do lado do servidor. O GitHub também foi aprimorado e foram adicionadas a ele diversas consultas específicas de dispositivos móveis, abordando problemas como tratamento de intenções, problemas de validação de modo de exibição da Web, injeção de fragmento e muito mais.

Para saber mais sobre a verificação de código, confira "Sobre a verificação de código com o CodeQL".

Os usuários em uma instância com uma licença do GitHub Advanced Security que usam a verificação de código CodeQL podem personalizar a configuração de build para análise do Go no arquivo de fluxo de trabalho do GitHub Actions. Os fluxos de trabalho existentes do CodeQL para análise do Go não exigem alterações e continuarão tendo suporte. Para obter mais informações, confira "Como configurar o fluxo de trabalho do CodeQL para linguagens compiladas".

Para aprimorar a segurança do código e simplificar o processo de atualização de dependências vulneráveis, mais usuários podem receber solicitações de pull automáticas com atualizações de dependência.

• GitHub Actions autores podem atualizar dependências automaticamente em arquivos de fluxo de trabalho.
• Os desenvolvedores do Dart ou do Flutter que usam o Pub podem atualizar automaticamente as dependências nos próprios projetos.

Para obter mais informações, confira "Sobre as atualizações de segurança do Dependabot".

Os desenvolvedores de Dardo e JavaScript em uma instância com o grafo de dependência habilitado podem receber alertas do Dependabot para vulnerabilidades conhecidas dentro das dependências de um projeto.

• Para o Dart, o grafo de dependência detecta arquivos pubspec.lock e pubspec.yaml.
• Os desenvolvedores de JavaScript que usam Node.js e npm podem receber alertas de vulnerabilidades conhecidas nos manifestos Yarn v2 e v3. Isso complementa o suporte existente para manifestos v1. O grafo de dependência detecta arquivos package.json e yarn.lock.

Para obter mais informações, consulte os seguintes artigos.

• "Sobre o grafo de dependência"
• "Como procurar avisos de segurança no GitHub Advisory Database"
• "Sobre alertas do Dependabot"

Os desenvolvedores do Python que usam gerenciadores de pacotes com suporte em uma instância com o grafo de dependência habilitado podem receber alertas do Dependabot para dependências em arquivos pyproject.toml que seguem o padrão PEP 621. Para obter mais informações, confira "Sobre as atualizações de versão do Dependabot".

Os desenvolvedores do Python que recebem alertas do Dependabot podem reduzir o número de atualizações de versão quando um requisito de dependência atual já é atendido por uma nova versão. Para configurar esse comportamento, use a estratégia de controle de versão increase-if-necessary. Para obter mais informações, confira "Opções de configuração para o arquivo dependabot.yml".

Os proprietários de empresa podem recuperar alertas do Dependabot para a instância usando a API REST. Esse ponto de extremidade está na versão beta e sujeito a alterações. Para obter mais informações, confira "Alertas do Dependabot" na documentação da API REST.

Os proprietários de organização podem recuperar alertas do Dependabot para a organização usando a API REST. Esse ponto de extremidade está na versão beta e sujeito a alterações. Para obter mais informações, confira "Alertas do Dependabot".

Os usuários podem exibir alertas do Dependabot e agir com base neles programaticamente, usando a API REST. Novos pontos de extremidade para exibir, listar e atualizar alertas do Dependabot estão disponíveis na versão beta. Esses pontos de extremidade estão sujeitos a alterações. Para obter mais informações, confira "Alertas do Dependabot" na documentação da API REST.

Para aumentar a visibilidade da postura de segurança e melhorar a análise de risco, os usuários podem acessar a cobertura e as exibições de risco dentro da visão geral de segurança. A exibição de cobertura mostra a habilitação entre repositórios, enquanto a exibição de risco exibe alertas entre repositórios. Proprietários da organização, gerentes de segurança e administradores de repositório em uma instância com uma licença do GitHub Advanced Security podem habilitar recursos de segurança na exibição de cobertura da visão geral de segurança. Os modos de exibição substituem a página "Visão geral". Eles estão em versão beta pública e sujeitos a alterações. Para obter mais informações, confira "Sobre a visão geral de segurança".

Os colaboradores podem definir a política de segurança de um repositório criando um arquivo SECURITY.md. Para aumentar a visibilidade da política, o GitHub Enterprise Server vinculará à política da guia Código do repositório. Para obter mais informações, confira "Como adicionar uma política de segurança ao seu repositório".

A API de revisão de dependência está em disponibilidade geral e a GitHub Action associada agora permite que os usuários referenciem um arquivo de configuração local ou externo. Para saber mais, confira a seguinte documentação.

• "Revisão de dependência" na documentação da API REST
• "Como configurar a revisão de dependência"

A API do GraphQL fornece acesso ao grafo de dependência de um repositório. Esse recurso está em versão prévia e sujeito a alterações. Para saber mais, confira "Objetos" na documentação da API do GraphQL.

Durante a configuração do armazenamento para o GitHub Actions, os administradores do site podem evitar riscos associados à entrada de segredos confidenciais e chaves de acesso usando o OIDC para se conectar a provedores de armazenamento de objetos. O GitHub Actions no GitHub Enterprise Server dá suporte a OIDC para conexões com a AWS, o Azure e o Google Cloud Platform. Esse recurso está na versão beta e sujeito a alterações. Para obter mais informações, confira "Como habilitar o GitHub Actions para o GitHub Enterprise Server".

Para evitar o registro em log não confiável de dados dos comandos de fluxo de trabalho set-state e set-output, os autores de ação podem usar arquivos de ambiente para gerenciamento de estado e saída.

• Para usar esse recurso, o aplicativo executor precisa ser de versão 2.297.0 ou posterior. As versões 2.298.2 e posteriores avisarão os usuários que usam os comandos save-state ou set-output. Esses comandos serão totalmente desabilitados em uma versão futura.
• Para usar as funções saveState e setOutput atualizadas, os fluxos de trabalho que usam o kit de ferramentas do GitHub Actions precisam chamar o @actions/core v1.10.0 ou posterior.

Para obter mais informações, confira "Comandos de fluxo de trabalho do GitHub Actions".

A capacidade de compartilhar ações e fluxos de trabalho reutilizáveis de repositórios privados está em disponibilidade geral. Os usuários podem compartilhar fluxos de trabalho em um repositório privado com outros repositórios privados pertencentes à mesma organização ou conta de usuário ou com todos os repositórios privados na instância. Para saber mais, confira a seguinte documentação.

• "Como gerenciar as configurações do GitHub Actions para um repositório"
• "Permissões de GitHub Actions" na documentação da API REST

Os usuários podem aprimorar a legibilidade do fluxo de trabalho e evitar a necessidade de armazenar dados de configuração não confidenciais como segredos criptografados definindo variáveis de configuração, que permitem a reutilização entre fluxos de trabalho em um repositório ou organização. Esse recurso está na versão beta e sujeito a alterações. Para obter mais informações, confira "Variáveis".

Os usuários podem nomear dinamicamente as execuções de fluxo de trabalho. run-name aceita expressões, e o nome dinâmico aparece na lista de execuções de fluxo de trabalho. Para obter mais informações, confira "Sintaxe de fluxo de trabalho do GitHub Actions".

Os usuários podem impedir que um trabalho seja executado em um executor fora do grupo pretendido definindo os nomes dos grupos de executores pretendidos para um fluxo de trabalho dentro da chave runs-on.

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

Além disso, o GitHub Enterprise Server não permitirá mais a criação de grupos de executores com nomes idênticos no nível da organização e da empresa. Uma faixa de aviso será exibida para qualquer grupo de executores em uma organização que compartilhe um nome com um grupo de executores para a empresa.

Os usuários podem impor práticas padrão de CI/CD em todos os repositórios de uma organização definindo os fluxos de trabalho necessários. Esses fluxos de trabalho são disparados como verificações de status necessárias para todas as solicitações de pull direcionadas ao branch padrão dos repositórios, que bloqueia a mesclagem até a aprovação na verificação. Esse recurso está na versão beta e sujeito a alterações. Para obter mais informações, confira "Fluxos de trabalho necessários".

Para habilitar a padronização das configurações do OIDC em fluxos de trabalho de implantação de nuvem, os proprietários de organização e os administradores de repositório podem configurar o formato de declaração subject em tokens OIDC definindo um modelo personalizado. Para obter mais informações, confira "Sobre a proteção de segurança com o OpenID Connect".

Para habilitar mais transparência e controle sobre o uso de cache em repositórios, os usuários que armazenam dependências em cache e outros arquivos reutilizados com actions/cache podem gerenciar caches da interface do usuário da Web da instância. Para obter mais informações, confira "Como armazenar dependências em cache para acelerar os fluxos de trabalho".

Os usuários podem definir expectativas em torno da disponibilidade exibindo um fuso horário local nos próprios perfis. Pessoas que exibirem o perfil ou o hovercard do usuário verão o fuso horário, bem como quantas horas atrás ou à frente eles estão em relação à hora local do usuário. Para obter mais informações, confira "Como personalizar seu perfil".

Para aprimorar a capacidade de descoberta, o GitHub Discussions apresenta os aprimoramentos a seguir.

• Os proprietários do repositório podem fixar discussões em uma categoria específica.
• Os títulos e descrições de categoria são exibidos na página da categoria.

Para gerenciar como os membros da organização bifurcam repositórios, os proprietários de organização podem definir uma política de criação de forks dedicada para qualquer organização. Essa política precisa ser mais rigorosa do que um conjunto de políticas de criação de forks para a empresa. Para obter mais informações, confira "Como gerenciar a política de criação de forks para sua organização".

Os proprietários de organização podem aprimorar a segurança da organização impedindo que colaboradores externos solicitem a instalação de aplicativos GitHub e OAuth. Para obter mais informações, confira "Como limitar as solicitações de acesso ao Aplicativo do OAuth e ao Aplicativo do GitHub".

Para evitar fornecer acesso administrativo completo a um repositório quando desnecessário, os administradores do repositório podem criar uma função personalizada que permita que os usuários ignorem as proteções de branch. Para impor proteções de branch para todos os usuários com acesso administrativo ou permissões de bypass, os administradores podem habilitar Não permitir ignorar as configurações acima. Para obter mais informações, confira "Como gerenciar funções de repositório personalizadas para uma organização" e "Sobre branches protegidos."

Os administradores do repositório podem garantir a segurança e a estabilidade dos branches exigindo a aprovação da solicitação de pull por alguém diferente do último pusher ou bloqueando o branch. Para obter mais informações, confira "Sobre os branches protegidos".

Em cenários em que alguém deve examinar o código em um fluxo de trabalho do GitHub Actions antes que o fluxo de trabalho seja executado, os administradores do repositório podem exigir aprovação de um usuário com acesso de gravação ao repositório antes que uma execução de fluxo de trabalho possa ser disparada de um fork privado. Para obter mais informações, confira "Como gerenciar as configurações do GitHub Actions para um repositório".

A API do GraphQL dá suporte à criação e remoção do vínculo entre um branch e um problema. Para saber mais, confira a seguinte documentação.

• "Criar um branch para trabalhar em um problema"
• "createLinkedBranch" e "deleteLinkedBranch" na documentação da API do GraphQL "Mutações"
• "Objetos" na documentação da API do GraphQL

Os usuários podem marcar uma versão específica em um repositório como a versão mais recente usando a interface do usuário da Web, a API REST ou a API do GraphQL. Para saber mais, confira a seguinte documentação.

• "Como gerenciar versões em um repositório"
• "Versões" na documentação da API REST
• "Objetos" na documentação da API do GraphQL

Os usuários podem economizar tempo e alternar o contexto com menos frequência recebendo atualizações em tempo real sobre a atividade do GitHub Enterprise Server diretamente no Slack ou no Microsoft Teams, e agindo com base nessas atualizações. As integrações do GitHub para esses serviços agora estão em disponibilidade geral. Para obter mais informações, confira "Extensões e integrações do GitHub".

Quando um administrador do site executa um comando usando o acesso SSH administrativo, o comando agora é registrado. Para ajudar o Suporte do GitHub a solucionar problemas e depurar, os pacotes de suporte incluem um log que contém esses comandos.

Para simplificar a descoberta de eventos nos logs de auditoria de empresa, organização ou usuário, a barra de pesquisa agora exibe uma lista de filtros disponíveis.

Antes que um administrador do site possa migrar do GitHub Enterprise Server usando a CLI do GitHub Enterprise Importer, a API do GraphQL startRepositoryMigration ou a API REST Iniciar uma migração da organização, o administrador precisa usar o Console de Gerenciamento para configurar um provedor de armazenamento de blobs para o armazenamento de arquivos de migração. Os recursos com suporte incluem o Amazon S3 e o Armazenamento de Blobs do Azure. Anteriormente, o armazenamento de blobs não era necessário e, opcionalmente, podia ser configurado usando gh gei. Essa alteração adiciona suporte para migrações em que a origem ou os metadados do Git são maiores que 1 GB.

Para ajudar os usuários em uma instância com uma licença do GitHub Advanced Security a entender melhor os segredos detectados e tomar medidas, os alertas de verificação de segredo sobre chaves de API de terceiros agora incluem um link para a documentação do provedor. Para obter mais informações, confira "Sobre a verificação de segredos".

Os usuários em uma instância com uma licença GitHub Advanced Security agora verão as ações que os usuários executaram em um alerta de verificação de segredo diretamente dentro da linha do tempo do alerta, incluindo quando um colaborador ignorou a proteção de push para um segredo.

As instâncias com uma licença do GitHub Advanced Security executarão regularmente uma verificação histórica para detectar tipos de segredo recém-adicionados em repositórios com o GitHub Advanced Security e a verificação de segredo habilitadas. Anteriormente, os usuários precisavam executar manualmente uma verificação histórica.

Nas instâncias com uma licença do GitHub Advanced Security, para garantir que as versões futuras do GitHub Enterprise Server sempre possam exibir uma visualização de um segredo detectado nas APIs ou na interface do usuário da Web, os segredos detectados já são armazenados separadamente do código-fonte. Os segredos detectados são armazenados usando criptografia simétrica. [Atualizado em 15-02-2023]

Ao usar registros privados para atualizações do Dependabot, o GitHub Enterprise Server se comporta com mais segurança. Se um registro privado estiver configurado para qualquer um dos ecossistemas a seguir, a instância não fará mais nenhuma solicitação de pacote para registros públicos.

• bundler
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

Para obter mais informações, confira "Opções de configuração para o arquivo dependabot.yml".

Os desenvolvedores do Elixir que usam repositórios Hex auto-hospedados podem configurar um registro privado para atualizações de versão do Dependabot no GitHub Enterprise Server. Para obter mais informações, confira "Opções de configuração para o arquivo dependabot.yml".

Os alertas do Dependabot apresentam os aprimoramentos de usabilidade a seguir.

• A página de um alerta é atualizada automaticamente depois que o Dependabot tenta criar uma solicitação de pull para uma atualização.
• Os alertas são mapeados com mais precisão para solicitações de pull de atualizações do Dependabot.
• Para melhorar o alerta para a comunidade, os usuários podem sugerir aprimoramentos nos alertas diretamente no Banco de Dados de Consultoria do GitHub.

Os usuários podem mencionar @dependabot com mais facilidade. Ao mencionar usuários, a conta de usuário do Dependabot agora aparece como uma sugestão de preenchimento automático.

Em repositórios com dependências vulneráveis, o Dependabot não exibirá mais uma faixa amarela. Para notificar os colaboradores sobre dependências vulneráveis, a guia Segurança exibe um contador de alertas.

Se um usuário cria um fork de um repositório com uma configuração existente do Dependabot no dependabot.yml, as atualizações do Dependabot serão desabilitadas no fork por padrão. Para habilitar atualizações no fork, o usuário precisa visitar as configurações de segurança e análise de código do repositório. Para obter mais informações, confira "Como configurar as atualizações de versão do Dependabot".

Os integradores que desejam receber um webhook para alertas do Dependabot precisam usar o novo webhook dependabot_alert. Esse webhook substitui o webhook repository_vulnerability_alert. Para obter mais informações, confira "Eventos e cargas do webhook".

Para melhorar a legibilidade de fluxos de trabalho do GitHub Actions que fazem referência a outras ações por SHA de confirmação, os autores de ação geralmente escrevem um comentário, incluindo a versão semântica correspondente na linha que chama a ação. Para economizar tempo, as solicitações de pull para atualizações de versão do Dependabot agora atualizarão automaticamente a versão semântica nesses comentários.

Os desenvolvedores de JavaScript que usam atualizações de segurança do Node.js, do npm e do Dependabot podem economizar tempo ao atualizar projetos npm com dependências transitivas.

• O Dependabot pode atualizar simultaneamente as dependências pai e filho. Anteriormente, o Dependabot não atualizava as dependências transitivas quando o pai exigia um intervalo de versão específico incompatível, exigindo atualizações manuais.
• O Dependabot pode criar solicitações de pull que resolvem alertas nos casos em que uma atualização para uma dependência direta removeria a dependência transitiva vulnerável da árvore.

Para obter mais informações, confira "Sobre as atualizações de segurança do Dependabot".

Para pessoas que usam o Dependabot para atualizações de versão no ecossistema do Docker, o Dependabot atualizará proativamente as marcas de imagem do Docker nos manifestos do Kubernetes. Para obter mais informações, confira "Como configurar as atualizações de versão do Dependabot" e "Opções de configuração para o arquivo dependabot.yml".

Vários aprimoramentos estão disponíveis para usuários que contribuem para avisos de segurança em GitHub.com, incluindo as alterações a seguir.

• Para garantir uma revisão mais rápida, o GitHub solicita que os usuários adicionem um motivo para a alteração.
• Para garantir que a contribuição corresponda à intenção do usuário, o GitHub não reordenará os links de referência na comparação.

O GitHub Actions apresenta os aprimoramentos de detectabilidade e acessibilidade a seguir.

• A experiência de navegação para pesquisar fluxos de trabalho e execuções de fluxo de trabalho foi aprimorada.
• A estrutura adicionada representa melhor a hierarquia entre o chamador e os fluxos de trabalho reutilizáveis.
• A experiência de navegação móvel é mais consistente e dá suporte a vários tamanhos de visor.

Os fluxos de trabalho do GitHub Actions não serão mais disparados infinitamente ao usar eventos GITHUB_TOKEN com workflow_dispatch e repository_dispatch. Antes dessa alteração, os eventos disparados por GITHUB_TOKEN não criariam uma execução de fluxo de trabalho. Para obter mais informações, confira "Como disparar um fluxo de trabalho".

Para execuções agendadas de fluxos de trabalho do GitHub Actions, os usuários verão informações adicionais sobre o repositório, a organização e a empresa dentro do conteúdo de github.event.

Os usuários de GitHub Actions têm um melhor insight do progresso de um trabalho ao usar regras de proteção do ambiente. O webhook workflow_job dá suporte a um novo estado waiting sempre que um trabalho aguarda uma regra de proteção do ambiente. Além disso, quando um trabalho se referir a uma chave environment na própria definição yaml, o conteúdo do webhook workflow_job também incluirá uma nova propriedade, deployment. deployment contém metadados sobre a implantação que a execução de verificação criou. Para obter mais informações, confira "Como usar ambientes para implantação".

Os proprietários da organização podem encontrar um contexto mais significativo em eventos de log de auditoria.

• Os eventos business.sso_response e org.sso_response aparecem na API REST e nos conteúdos para streaming de log de auditoria.
• Os eventos repo.rename, project.rename e protected_branch.update_name incluem os nomes atuais e anteriores para esses renomeados dentro do campo old_name.
• Os eventos para alertas do Dependabot contêm os campos alert_number, ghsa_id, dismiss_reason e dismiss_comment, além de um link de volta para o alerta e um carimbo de data/hora preciso.

Os usuários podem exibir uma lista que contém todos os seguidores de uma organização do perfil da organização.

A faixa exibida em cima de um repositório arquivado na interface do usuário da Web agora inclui a data de arquivamento do repositório.

As guias Conversas e Arquivos em solicitações de pull agora são carregadas mais rapidamente devido ao realce de sintaxe adiado.

Para fornecer uma experiência mais consistente entre a interface do usuário da Web e as estações de trabalho dos usuários e acelerar o processo de verificar se os usuários podem mesclar uma solicitação de pull automaticamente, o GitHub Enterprise Server agora usa a estratégia merge-ort. Para obter mais informações, confira Estratégias de mesclagem na documentação do Git.

Para aprimorar a exibição do comentário inicial em solicitações de pull que contêm um commit, o GitHub Enterprise Server agora reformata automaticamente mensagens de confirmação detalhadas para aderir às convenções de Markdown do GitHub.

Antes de mesclar um solicitação de pull por squash, a interface do usuário da Web exibe o endereço de email do autor do commit. Anteriormente, o autor do commit só era exibido ao mesclar com um commit de mesclagem.

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

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

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

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

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

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

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

Em alguns casos, ao converter um problema em uma discussão, o processo de conversão pode travar. Nessa situação, o proprietário de uma empresa pode tentar as seguintes etapas de solução de problemas para resolvê-lo.

1. No final do URL da discussão travada, anote o número da discussão.
2. Na interface do usuário da Web, navegue até o repositório onde a conversão está travada.
3. No canto superior direito da interface do usuário da Web, clique em .
4. Em "Colaboração", clique em NÚMERO de discussões.
5. Na lista, clique no número da etapa 1.
6. Em "Conversão", clique em Enfileirar trabalho de conversão.
7. Aguarde alguns minutos e verifique o status do problema.

Se a conversão ainda não tiver sido concluída, entre em contato com o suporte do GitHub Enterprise para obter assistência.

Se o administrador do site raiz estiver bloqueado do console de gerenciamento após tentativas de logon com falha, a conta não será desbloqueada automaticamente após o tempo de bloqueio definido. Alguém com acesso SSH administrativo à instância precisa desbloquear a conta usando o shell administrativo. Para obter mais informações, confira "Solução de problemas de acesso ao Console de Gerenciamento". [Atualizado em 23-02-2023]

Durante uma atualização para o GitHub Enterprise Server 3.8.0 em um cluster, após a atualização de nós diferentes do nó primário do MySQL e antes da atualização desse nó, o erro a seguir pode ser exibido várias vezes após a execução de ghe-cluster-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

O GitHub recomenda aguardar até que esse problema seja resolvido para atualizar o cluster. Mais informações estarão disponíveis nas notas sobre a versão de uma próxima atualização do GitHub Enterprise Server.

Depois de atualizar para o GitHub Enterprise Server 3.8.0, os comandos executados por meio de SSH em qualquer um dos nós da instância não serão registrados no /var/log/ssh-console-audit.log. Para resolver esse problema, use o SSH no nó afetado e execute o comando a seguir.

source /etc/bash.bashrc

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

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

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

O uso da API de pesquisa poderá causar uma falha nas solicitações seguintes para outras interfaces. Quando esse problema ocorrer, os usuários da API ou da interface do usuário da Web afetados receberão respostas HTTP 5xx e a exceção NoMethodError será registrada em log:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):

Em uma instância com uma licença de GitHub Advanced Security em que a verificação de segredo está habilitada, o log excessivo em /var/log pode causar erros voltados para o usuário e degradar o desempenho do sistema se os logs consumirem todo o espaço livre no volume. Para evitar que esse problema afete os usuários, monitore o espaço livre no volume raiz da instância. Para obter mais informações, confira "Como configurar a verificação de segredo para seu dispositivo" e "Como monitorar seu dispositivo". Se você suspeitar que esse problema está afetando sua instância e precisar de ajuda, entre em contato com o suporte do GitHub. [Atualizado em 03-05-2023]