Enterprise Server 3.6 release notes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On an instance in a cluster configuration, when a site administrator sets maintenance mode on a single cluster node using ghe-maintenance -s, the utility warns the administrator to use ghe-cluster-maintenance -s to set maintenance mode on all of the clusters nodes. For more information, see "Activation et planification du mode de maintenance."

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

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

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "Utilitaires de ligne de commande."

ÉLEVÉE : Une vulnérabilité de traversée de chemin a été identifiée dans GitHub Enterprise Server, qui permettait l’exécution de code distant lors de la génération d’un site GitHub Pages. Pour exploiter cette vulnérabilité, un attaquant avait besoin de l’autorisation de créer et générer un site GitHub Pages sur l’instance GitHub Enterprise Server. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2023-23760.

Lors de l’affichage d’une liste de sessions ouvertes pour les appareils connectés à un compte d’utilisateur, l’interface utilisateur web GitHub Enterprise Server peut afficher un emplacement incorrect.

Dans les rares cas où les partitions principales pour Elasticsearch étaient situées sur un nœud de réplica, la commande ghe-repl-stop échouait avec ERROR: Running migrations.

La page des paramètres pour les discussions dans une organisation a renvoyé une erreur 500 après la suppression d’un dépôt appartenant à l’organisation.

ÉLEVÉE : Mise à jour de Git pour inclure les correctifs de la version 2.39.2, qui répondent à CVE-2023-22490 et CVE-2023-23946.

Les packages ont été mis à jour avec les dernières versions de sécurité.

Lors de l’utilisation d’une URL de point de terminaison VPC en tant qu’URL AWS S3 pour les packages GitHub, la publication et l’installation des packages échouaient.

Sur une instance avec une licence GitHub Advanced Security, si l’analyse du code a été utilisée lors de l’exécution de GitHub Enterprise Server 3.4 ou version antérieure, une mise à niveau ultérieure de la version 3.5 vers 3.6 ou 3.7 peut échouer lors de la tentative d’ajout d’un index unique à une table de base de données.

MOYENNE : Une vulnérabilité d’injection de code a été identifiée dans GitHub Enterprise Server qui permettait de définir des variables d’environnement arbitraires à partir d’une seule valeur de variable d’environnement dans GitHub Actions lors de l’utilisation d’un exécuteur Windows à cause d’un assainissement incorrect des octets Null. Pour exploiter cette vulnérabilité, un attaquant a besoin d’une autorisation existante pour contrôler la valeur des variables d’environnement à utiliser avec GitHub Actions. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2023-22381.

Les packages ont été mis à jour avec les dernières versions de sécurité.

Une fois qu’un administrateur de site a ajusté la date limite pour autoriser les connexions SSH avec des clés RSA à l’aide de ghe-config app.gitauth.rsa-sha1, l’instance interdit toujours les connexions avec des clés RSA si la tentative de connexion a été signée par la fonction de hachage SHA-1.

Pendant la phase de validation d’une exécution de configuration, une erreur No such object error a pu se produire pour les services Notebook et Viewscreen.

Lors de l’activation de la gestion automatique des certificats TLS avec Let’s Encrypt, le processus peut échouer avec l’erreur The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates.

Dans certains cas, les utilisateurs n’étaient pas en mesure de convertir les questions existantes en discussions. Si un problème est bloqué lors de la conversion en discussion, les propriétaires d’entreprise peuvent consulter la section « Problèmes connus » ci-dessous pour obtenir plus d’informations.

Quand un délai d’attente se produit pendant la génération de différences, par exemple lorsqu’un commit affiche une erreur indiquant que la génération des différences dure trop longtemps, l’événement de webhook push fournit des informations de différences vides. Auparavant, l’événement de webhook push ne pouvait pas être remis.

ÉLEVÉE : Mise à jour de Git pour inclure les correctifs de la version 2.39.1, qui répondent à CVE-2022-41903 et CVE-2022-23521.

Assainissement des secrets supplémentaires dans les offres groupées de support et dans le journal de configuration.

Les dépendances de l’action CodeQL ont été mises à jour vers les dernières versions de sécurité.

Les packages ont été mis à jour avec les dernières versions de sécurité.

Les métriques Active workers et Queued requests pour github (renommées à partir des métadonnées), gitauth et les services de conteneur unicorn n’étaient pas été correctement lus à partir de collectd et affichés dans la console de gestion.

Les e-mails d’alerte Dependabot étaient envoyés aux dépôts désactivés.

Les migrations de données pouvaient échouer lorsque la table de base de données sous-jacente ne contenait qu’un seul enregistrement.

Lors de l’affichage d’un écart de demande de tirage pour un fichier volumineux avec de nombreuses lignes entre les modifications, il n’était pas possible de développer la vue pour afficher toutes les modifications.

La commande git-janitor ne pouvait pas corriger les fichiers obsolètes multi-pack-index.lock, ce qui entraînait l’échec de la maintenance du dépôt.

La variable d’environnement GITHUB_REF_PROTECTED et les contextes github.ref_protected étaient été incorrectement définis comme false lorsque des protections de branche existaient.

Suppression des métriques launch.* qui ne peuvent pas être analysées par statsd, causant des erreurs statsd résultantes entraînant une augmentation rapide de la taille des journaux collectd.

Lors de la mise à jour de modèles personnalisés, l’état du modèle était immédiatement défini sur Publié.

Amélioration de la fiabilité du service de mises à jour en temps réel (Alive) pour le rendre plus résilient face aux problèmes réseau avec Redis.

Les commandes ghe-support-bundle et ghe-cluster-support-bundle ont été mises à jour pour inclure l’indicateur -p/--period afin de générer un bundle de support limité dans le temps. La durée peut être spécifiée en jours et heures, par exemple : -p '2 hours', -p '1 day', -p '2 days 5 hours'.

Lors de la mise à niveau d’une instance avec une nouvelle partition racine, l’exécution de la commande ghe-upgrade avec l’option -t/--target garantit que la vérification préalable de la taille de stockage disque minimale est exécutée sur la partition cible.

Les performances des exécutions de configuration démarrées avec ghe-config-apply ont été améliorées.

Lors de l’exportation de données de compte, de la sauvegarde d’un dépôt ou de l’exécution d’une migration, le lien vers une archive de dépôt expire maintenant après 1 heure. Auparavant, le lien d’archive expirait au bout de 5 minutes.

ÉLEVÉE : Une vulnérabilité de traversée de chemin a été identifiée dans GitHub Enterprise Server, qui permettait l’exécution de code distant lors de la génération d’un site GitHub Pages. Pour exploiter cette vulnérabilité, un attaquant avait besoin de l’autorisation de créer et générer un site GitHub Pages sur l’instance. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et s’est vu affecter le numéro CVE-2022-46256.

ÉLEVÉE : Une vulnérabilité d’autorisation incorrecte permettait à un jeton délimité utilisateur-à-serveur de passer à un accès administrateur total pour un dépôt. Un attaquant avait besoin d’un compte avec un accès administrateur pour installer une application GitHub malveillante. Cette vulnérabilité affectait toutes les versions de GitHub Enterprise Server antérieures à la version 3.7.0. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2022-23741.

MOYENNE : Une vulnérabilité de divulgation d’informations a été identifiée dans GitHub Enterprise Server qui permettait l’ajout de dépôts privés à un groupe d’exécuteurs GitHub Actions via l’API par un utilisateur qui n’avait pas accès à ces dépôts, ce qui entraînait l’affichage des noms des dépôts dans l’interface utilisateur. Pour exploiter cette vulnérabilité, un attaquant doit avoir un accès à l’instance GHES, des autorisations pour modifier les groupes d’exécuteurs GitHub Actions et deviner l’ID obfusqué des dépôts privés. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2022-46257.

Une condition de concurrence bloquait les mises à niveau vers GitHub Enterprise Server 3.6 ou ultérieur tant qu’un administrateur de site ne retentait pas la mise à niveau.

Les administrateurs de sites ne pouvaient pas gérer les paramètres des produits de sécurité des dépôts qu’ils avaient déverrouillés.

Lorsqu’un administrateur de site exécutait la commande ghe-repl-status sur un réplica de cache via le shell d’administration (SSH), la commande signalait mal les informations générales sur l’état de réplication des clusters Git et Alambic, comme si elles se rapportaient uniquement à la réplication du cache.

Lorsqu’un administrateur de site exécutait la commande ghe-repl-sync-ca-certificates à partir d’un nœud primaire d’instances via le shell d’administration (SSH), la commande répliquait uniquement les certificats d’autorité de certification du nœud primaire d’instances sur un seul nœud de réplica. La commande ne répliquait pas les certificats sur tous les nœuds de réplica disponibles.

Lors de l’utilisation de la mise en cache de dépôt avec une instance dans une configuration à haute disponibilité, si un client Git utilisait SSH au lieu de HTTPS pour une URL distante de dépôt, Git LFS récupérait les objets du nœud primaire des instances au lieu du nœud de réplica de cache approprié.

L’installation de GitHub Enterprise Server sur l’hyperviseur VMware ESXi échouait en raison de la génération d’un fichier OVA avec une valeur de capacité non valide.

Lorsque les utilisateurs effectuaient une opération à l’aide de l’API, GitHub Enterprise Server appliquait des quotas de taille de dépôt, même en cas de désactivation globale.

Si un utilisateur chargeait plusieurs fichiers lors de la création d’un Gist, il ne pouvait pas supprimer les fichiers chargés après le premier.

Dans certains cas, les recherches effectuées via l’API retournaient une erreur 500.

Dans certains cas, lors de la navigation dans les dépôts dans l’interface web, une bannière erronée indiquait qu’un dépôt ne contenait pas de chemin non défini spécifique sur la branche actuelle.

L’événement de webhook member n’incluait pas les valeurs de champ from et to pour le champ permission dans le cadre du champ changes.

L’ajout d’un collaborateur à une duplication appartenant à l’utilisateur d’un dépôt privé appartenant à l’organisation avec triage, maintenance ou accès personnalisé entraînait une erreur 500.

Dans certains cas, la page de configuration de l’analyse du code signalait par erreur que GitHub Actions n’était pas été configuré pour l’instance.

Une fois le compte d’utilisateur supprimé de l’instance, les pièces jointes d’images que l’utilisateur avaient chargées dans les commentaires n’étaient plus visibles dans l’interface web.

Un message au niveau du débogage apparaissait dans un journal système, ce qui pouvait consommer rapidement de l’espace sur le volume de stockage racine de l’instance.

Pour éviter l’échec de la vérification de domaine en raison de la limite à 63 caractères appliquée par les fournisseurs DNS pour les enregistrements DNS, l’enregistrement TXT généré par GitHub pour vérifier l’appartenance au domaine est maintenant limité à 63 caractères.

Une fois qu’un propriétaire d’entreprise active les alertes Dependabot, GitHub Enterprise Server met en file d’attente la synchronisation des données d’avis pour garantir les mises à jour toutes les heures à partir de GitHub.com.

La liste des dépôts récemment consultés par un utilisateur n’inclut plus les dépôts supprimés.

Pour les participants à la version bêta privée de SCIM pour GitHub Enterprise Server, les mappages personnalisés pour les attributs utilisateur SAML sont maintenant pris en charge. Les mappages personnalisés permettent d’utiliser une valeur autre que NameID comme revendication d’identification unique lors de l’authentification SAML. Pour plus d’informations, consultez « Configuration du provisionnement d’utilisateurs avec SCIM pour votre entreprise ». [Mise à jour : 27/02/2023]

MOYENNE : Mise à jour de CommonMarker pour résoudre un scénario où les requêtes parallèles adressées à l’API REST Markdown pouvaient entraîner une épuisement des ressources non liées. Cette vulnérabilité porte le numéro CVE-2022-39209.

MOYENNE : Les jetons délimités utilisateur-à-serveur des applications GitHub pouvaient contourner les vérifications d’autorisation dans les requêtes d’API GraphQL lors de l’accès aux ressources hors dépôt. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2022-23739.

MOYENNE : Les liens d’aperçu des demandes de tirage ne nettoyaient pas correctement les URL, ce qui permettait à un utilisateur malveillant d’incorporer des liens dangereux dans l’interface utilisateur web des instances. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty.

MOYENNE : Une vulnérabilité d’autorisation incorrecte a été identifiée dans GitHub Enterprise Server ; elle permettait à un jeton d’étendue de dépôt avec accès en lecture/écriture de modifier les fichiers de workflow GitHub Actions sans étendue de workflow. « Contenu d’un dépôt » doit appliquer l’étendue du workflow. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et s’est vu affecter le numéro CVE-2022-46258.

Si une dépendance GitHub Actions utilise une version SHA épinglée, Dependabot ne marque plus la dépendance comme vulnérable.

La définition du mode maintenance avec une liste d’exceptions IP n’est pas conservée entre les mises à niveau.

Les builds de GitHub Pages pouvaient expirer sur des instances dans AWS qui sont configurées pour la haute disponibilité.

Les détails d’état de la réplication d’objets Git LFS vers des nœuds de réplica du cache du référentiel n’étaient pas visibles dans la sortie ghe-repl-status de ces nœuds.

Après la configuration des e-mails Dependabot et de synthèse d’alerte, l’instance envoyait des e-mails de synthèse aux utilisateurs suspendus.

L’horodatage du journal d’audit pour les événements d’alerte Dependabot retournait la date de création de l’alerte au lieu de l’horodatage lorsqu’un utilisateur prenait une action sur l’alerte.

Lors de l’utilisation de l’action CodeQL, les annotations d’exécution incluaient une erreur fallacieuse HttpError: Upload not found.

Lors de l’accès à des ressources JavaScript d’instances à partir d’un proxy, le navigateur affichait des erreurs CORS (Cross-Origin Resource Sharing).

Si un utilisateur nommait une vérification d’état avec des espaces de début ou de fin, l’instance créait une vérification dupliquée si une autre vérification existait avec le même nom sans aucun espace de début ou de fin.

Si un utilisateur avait configuré un hook de pré-réception pour plusieurs dépôts, la page Hooks des instances n’affichait pas toujours l’état correct pour le hook.

Dans certains cas, une instance pouvait remplacer un dépôt actif par un dépôt supprimé.

Les objets Git LFS dans un dépôt avec une stratégie de réplication de cache n’étaient pas copiés dans le cache des réplicas si le nombre total d’objets dans le dépôt dépassait 5 000.

Après avoir exécuté des migrations pour GitHub Enterprise Importer sur une instance configurée pour la haute disponibilité, la réplication des ressources de stockage de migration ne rattrapait pas son retard.

Les processus zombies ne s’accumulent plus dans le conteneur gitrpcd.

Si un administrateur de site n’a pas encore configuré GitHub Actions pour l’instance, l’interface utilisateur pour configurer l’analyse du code invite l’utilisateur à configurer GitHub Actions.

ÉLEVÉE : Mise à jour des dépendances de la console de gestion vers les dernières versions correctives, qui corrigent plusieurs vulnérabilités de sécurité, notamment CVE-2022-30123 et CVE-2022-29181.

ÉLEVÉE : Ajout de vérifications pour résoudre une vulnérabilité de clé de cache incorrecte qui permettait à un acteur non autorisé d’accéder aux fichiers de dépôt privé via un dépôt public. Cette vulnérabilité porte le numéro CVE-2022-23738.

MOYENNE : Mise à jour de CommonMarker pour résoudre un scénario où les requêtes parallèles adressées à l’API REST Markdown pouvaient entraîner une épuisement des ressources non liées. Cette vulnérabilité porte le numéro CVE-2022-39209.

MOYENNE : Mise à jour de Redis vers la version 5.0.14 pour corriger les vulnérabilités CVE-2021-32672 et CVE-2021-32762.

MOYENNE : Mise à jour des exécuteurs GitHub Actions pour corriger un bogue qui permettait aux variables d’environnement dans les travaux GitHub Actions d’échapper au contexte de la variable et de modifier directement l’appel des commandes docker. Pour plus d’informations, consultez l’avis de sécurité pour l’exécuteur Actions.

MOYENNE : Une vulnérabilité de gestion des privilèges incorrecte a été identifiée dans GitHub Enterprise Server, qui permettait aux utilisateurs disposant de privilèges inappropriés de créer ou de supprimer des pages via l’API. Pour exploiter cette vulnérabilité, un attaquant devait être ajouté au dépôt d’une organisation avec des autorisations d’écriture. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et porte le numéro CVE-2022-23737.

FAIBLE : En raison d’une vulnérabilité de CSRF, une requête GET adressée au point de terminaison site/toggle_site_admin_and_employee_status de l’instance pouvait changer l’état d’administrateur de site d’un utilisateur sans le savoir.

Les packages ont été mis à jour avec les dernières versions de sécurité.

Une fois qu’un administrateur de site apportait une modification qui déclenchait une exécution de configuration, comme la désactivation de GitHub Actions, la validation des services échouait parfois avec le message WARNING: Validation encountered a problem.

Une fois qu’un administrateur de site installait un correctif à chaud contenant des modifications aux ressources de l’interface web, comme des fichiers ou images JavaScript, l’instance ne servait pas les nouvelles ressources.

Lorsqu’un utilisateur accédait à un dépôt renommé à l’aide de Git, le nom d’hôte dans la sortie Git indiquait incorrectement GitHub.com au lieu du nom d’hôte de l’instance.

Sur les instances utilisant l’authentification LDAP et la synchronisation LDAP, la synchronisation échouait et imprimait undefined method ord for nil:NilClass dans ldap-sync.log.

Lorsqu’un utilisateur visitait des liens pour afficher l’historique ou suggérer une amélioration de la base de données GitHub Advisory, les URL étaient incorrectes, ce qui entraînait une erreur 404.

Les ressources supprimées et les ressources planifiées pour être vidées dans un dépôt, comme les fichiers LFS, prenaient trop de temps pour être nettoyées.

Sur les instances configurées pour la haute disponibilité, ghe-repl-status signalait à tort que la réplication était en retard pour les dépôts que les utilisateurs avaient précédemment supprimés.

Si un utilisateur installait une application GitHub pour le compte d’utilisateur, puis convertissait le compte en organisation, l’application ne recevait pas d’autorisations d’organisation.

Les alertes d’analyse des secrets manquantes sur une instance avec une licence GitHub Advanced Security qui n’a pas été mise à niveau directement vers GitHub Enterprise Server 3.4 sont désormais visibles dans l’interface web et via l’API REST.

Dans certains cas, sur une instance avec une licence GitHub Advanced Security, certains jetons détectés par l’analyse des secrets étaient signalés comme des « jetons inconnus ».

Pour s’assurer que les administrateurs de site peuvent effectuer une mise à niveau, l’instance exécute désormais une vérification préliminaire pour s’assurer que la machine virtuelle répond à la configuration matérielle minimale requise. La vérification inspecte également l’intégrité d’Elasticsearch. Vous pouvez passer en revue la configuration actuelle requise pour le processeur, la mémoire et le stockage pour GitHub Enterprise Server dans la section « Configuration minimale requise » de chaque article dans « Configuration d’une instance GitHub Enterprise Server ».

Les archives de dépôt pour les migrations incluent désormais un champ is_archived.

ÉLEVÉE : Une application GitHub pouvait utiliser un jeton délimité utilisateur-à-serveur pour contourner la logique d’autorisation utilisateur et faire remonter les privilèges.

FAIBLE : Accorder à un utilisateur la possibilité de contourner les protections de branche ne permet plus à l’utilisateur de contourner la vérification de signature obligatoire.

Les packages ont été mis à jour avec les dernières versions de sécurité.

Dans certains cas, la collecte pouvait journaliser les erreurs excessives liées aux métriques dans /var/log/collectd.log.

Lors de la configuration du nom de domaine externe d’un nœud de réplica de cache de dépôt avec ghe-repl-node --cache-domain, la commande retournait une erreur qui empêchait l’activation de la mise en cache de Git LFS.

L’installation d’un certificat TLS échouait lorsque la chaîne d’objet du certificat comprenait des caractères UTF-8.

Les exécutions de configuration pouvaient échouer lorsque retry-limit ou retry-sleep-duration étaient définis manuellement par un administrateur à l’aide de ghe-config.

L’option permettant d’activer le chiffrement TLS pour les connexions SMTP entrantes à une instance était manquante dans la console de gestion.

Dans certains cas, le tableau de bord du moniteur de la console de gestion ne se chargeait pas correctement.

Suppression d’un lien non fonctionnel pour l’exportation de graphes du moniteur de la console de gestion en tant qu’images PNG.

La commande ghe-find-insecure-git-operations ne retournait pas toutes les opérations Git non sécurisées après chaque appel.

Lors de l’envoi d’un bundle de support au support GitHub Enterprise à l’aide de ghe-support-upload, l’option -t n’associait pas correctement le bundle chargé au ticket spécifié.

Un lien vers les paramètres de sécurité du compte d’entreprise de l’instance pouvait afficher une vue incorrecte.

Dans de rares cas, une mise à niveau de GitHub Enterprise Server 3.3 vers la version 3.4 modifiait mal la façon dont les données étaient stockées, ce qui entraînait des échecs lors des mises à niveau ultérieures. Lors de la mise à niveau directe vers cette version à partir de la version 3.3, l’échec ne se produit pas.

Lors de l’utilisation d’une URL de point de terminaison VPC en tant qu’URL AWS S3 pour les packages GitHub, la publication et l’installation des packages échouaient.

Les clones Git ou les extractions via SSH pouvaient subir une altération des données pour les transferts d’une taille supérieure à 1 Go.

Une fois qu’un utilisateur supprimait ou restaurait des packages de l’interface web, le nombre de packages pouvait être mal restitué.

Une fois la configuration réussie des e-mails Dependabot et de synthèse des alertes, l’instance n’envoyait pas d’e-mails de synthèse.

Les workflows GitHub Actions désactivés manuellement d’un dépôt étaient réactivés si le dépôt recevait une poussée contenant plus de 2 048 commits, ou si la branche par défaut du dépôt changeait.

Lors de l’affichage d’un diff de demande de tirage pour un gros fichier avec de nombreuses lignes entre les modifications, il n’était pas possible de développer la vue pour afficher toutes les modifications.

Si les protections de branche étaient activées, la variable d’environnement GITHUB_REF_PROTECTED et les contextes github.ref_protected pour les exécutions de workflow GitHub Actions étaient définis par erreur comme false.

Les dépôts pour les packages affichaient par erreur une section « Utilisé par ».

Après avoir déverrouillé un référentiel pour un accès temporaire, un administrateur de site ne pouvait pas gérer les paramètres des produits de sécurité dans le référentiel.

Des clés SSH administratives en double pouvaient apparaître à la fois dans la console de gestion et dans le fichier /home/admin/.ssh/authorized_keys.

La page d’administration de site pour les utilisateurs individuels sur http(s)://HOSTNAME/stafftools/users/USERNAME/admin contenait des fonctionnalités non destinées à GitHub Enterprise Server.

Dans certains cas, l’exécution de ghe-cluster-config-apply pouvait répliquer une configuration vide sur les nœuds existants d’un cluster.

Dans certains cas, les exécutions de configuration démarrées avec ghe-config-apply ne se terminaient pas ou retournaient une erreur Container count mismatch.

Après la mise à jour d’un certificat TLS auto-signé sur une instance GitHub Enterprise Server, les éléments de l’interface utilisateur de certaines pages de l’interface web n’apparaissaient pas.

Dans certains cas, les tâches d’arrière-plan pouvaient se bloquer à cause d’une bibliothèque qui était utilisée simultanément bien qu’elle ne soit pas thread-safe.

La barre d’administration du site située en haut de l’interface web contenait un lien brisé vers le SHA de la version exécutée de l’application.

Les propriétaires d’organisations ne pouvaient pas définir le niveau d’accès requis pour créer des discussions.

Les utilisateurs de discussions étaient dirigés à tort vers les directives communautaires de GitHub.com.

Dans certains cas, les utilisateurs étaient informés à tort qu’ils devaient vérifier leur adresse e-mail avant de créer une discussion.

Les alertes provenant de l’analyse des secrets pour les clients GitHub Advanced Security étaient absentes de l’interface web et de l’API REST si un administrateur de site n’effectuait pas directement la mise à niveau vers GitHub Enterprise Server 3.4. Les alertes sont maintenant visibles.

La génération des packs de support est plus rapide grâce à la parallélisation de l’assainissement des journaux. Pour plus d’informations sur les packs de support, consultez « Fournir des données au support GitHub ».

Les API qui contiennent la route organization ou org acceptent désormais le slug ou l’ID de l’organisation. Avant, les API n’acceptaient que les slugs, ce qui rendait inaccessibles les en-têtes Link des points de terminaison GitHub Advanced Security. Pour plus d’informations, consultez « Organisations » dans la documentation de l’API REST.

Le journal d’audit de l’entreprise inclut désormais davantage d’événements générés par les utilisateurs, comme project.create. L’API REST retourne également d’autres événements générés par les utilisateurs, comme repo.create. Pour plus d’informations, consultez « Accès au journal d’audit de votre entreprise » et « Utilisation de l’API de journal d’audit pour votre entreprise ».

Dans certains cas, les réplicas du cache pouvaient rejeter certaines opérations Git sur des référentiels récemment mis à jour. Pour plus d’informations sur la mise en cache des dépôts, consultez « À propos de la mise en cache des dépôts ».

Vous pouvez désormais configurer la bannière d’annonce globale pour qu’elle soit révocable à l’aide de l’API REST. Pour plus d’informations, consultez « Personnalisation des messages utilisateur pour votre entreprise ».

La mise en cache du référentiel est en disponibilité générale. La mise en cache du référentiel augmente les performances de lecture de Git pour les développeurs distribués, en offrant la localité des données et la commodité de la géo-réplication sans impact sur les workflows d’envoi. Avec la version en disponibilité générale, GitHub Enterprise Server met en cache les données Git et Git LFS. Pour plus d’informations, consultez « À propos de la mise en cache des dépôts ».

Les administrateurs de site peuvent configurer une date limite pour autoriser les opérations Git sur SSH qui utilisent une clé RSA et sont signées par la fonction de hachage SHA-1. Par défaut, ces connexions échouent pour les clés RSA ajoutées aux comptes d’utilisateur après la date limite du 1er août 2022 minuit UTC. Pour plus d’informations, consultez Dépréciations. [Mise à jour : 31/01/2023]

GitHub Enterprise Server autorise éventuellement la publication d’une clé d’hôte Ed25519. Pour plus d’informations, consultez « Configuration des clés d’hôte pour votre instance ».

Vous pouvez exiger le chiffrement TLS pour les connexions SMTP entrantes pour votre instance. Pour plus d’informations, consultez « Configuration de l’e-mail pour les notifications ».

• Remarque : Cette fonctionnalité n’est pas disponible dans GitHub Enterprise Server 3.6.0 et 3.6.1. La fonctionnalité est disponible dans la version 3.6.2. [Mise à jour : 22/09/2022]

Vous pouvez diffuser les journaux d’audit et les événements Git de votre instance vers Amazon S3, Stockage Blob Azure, Azure Event Hubs, Google Cloud Storage ou Splunk. La diffusion en continu des journaux d’audit est en version bêta publique et est sujette à des modifications. Pour plus d’informations, consultez « Streaming de journaux d’audit pour votre entreprise ».

Server Statistics est maintenant en disponibilité générale. Server Statistics collecte les données d’utilisation agrégées de votre instance GitHub Enterprise Server, que vous pouvez utiliser pour mieux anticiper les besoins de votre organisation, comprendre comment votre équipe travaille et montrer la valeur que vous tirez de GitHub Enterprise Server. Pour plus d’informations, consultez « À propos des statistiques du serveur ».

Les propriétaires d’entreprise peuvent rejoindre les organisations de l’instance en tant que membre ou propriétaire à partir de la page Organisations du compte d’entreprise. Pour plus d’informations, consultez « Gestion de votre rôle dans une organisation appartenant à votre entreprise ».

Les propriétaires d’entreprise peuvent autoriser les utilisateurs à rejeter la bannière d’annonce globale configurée. Pour plus d’informations, consultez « Personnalisation des messages utilisateur pour votre entreprise ».

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent choisir de recevoir un événement webhook qui se déclenche lorsqu’un propriétaire d’organisation ou un administrateur de référentiel active ou désactive une fonction de sécurité ou d’analyse du code. Pour plus d’informations, consultez la documentation suivante.

• « Événements et charges utiles de webhook » dans la documentation du webhook
• « Gestion des paramètres de sécurité et d’analyse pour votre organisation »
• « Gestion des fonctionnalités de sécurité et d’analyse de votre dépôt »

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent éventuellement ajouter un commentaire lorsqu’ils rejettent une alerte d’analyse de code dans l’interface web ou via l’API REST. Les commentaires de rejet apparaissent dans la chronologie de l’événement. Les utilisateurs peuvent également ajouter ou récupérer un commentaire de rejet via l’API REST. Pour plus d’informations, consultez « Triage des alertes d’analyse du code dans les demandes de tirage (pull request) » et « Analyse du code » dans la documentation de l’API REST.

Sur les instances disposant d’une licence GitHub Advanced Security, l’analyse des secrets empêche la fuite des secrets dans l’éditeur web. Pour plus d’informations, consultez « Protection des poussées avec l’analyse des secrets ».

Les propriétaires d’entreprise et les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent voir les alertes d’analyse des secrets et les contournements de la protection push de l’analyse des secrets dans les journaux d’audit de l’entreprise et de l’organisation, et via l’API REST. Pour plus d’informations, consultez la documentation suivante.

• « Protection des poussées (push) avec l’analyse des secrets »
• « Événements du journal d’audit pour votre entreprise »
• « Examen du journal d’audit de votre organisation »
• « Analyse de secrets » dans la documentation de l’API REST

Les propriétaires d’entreprise sur une instance avec une licence GitHub Advanced Security peuvent effectuer des tests des modèles d’analyse des secrets personnalisés pour l’entreprise, et tous les utilisateurs peuvent effectuer des tests lors de la modification d’un modèle. Les tests vous permettent de comprendre l’impact d’un modèle sur l’ensemble de l’instance et d’affiner le modèle avant sa publication et la génération d’alertes. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent utiliser les paramètres sort et direction dans l’API REST lorsqu’ils récupèrent des alertes d’analyse des secrets, et les trier en fonction des champs created ou updated de l’alerte. Les nouveaux paramètres sont disponibles pour l’instance entière, ou pour des organisations ou des référentiels individuels. Pour plus d’informations, consultez la documentation suivante.

• « Répertorier les alertes d’analyse des secrets pour une entreprise »
• « Répertorier les alertes d’analyse des secrets pour une organisation »
• « Répertorier les alertes d’analyse des secrets pour un dépôt »
• « Analyse de secrets » dans la documentation de l’API REST

Le contenu du référentiel github/codeql-go a été déplacé vers le référentiel github/codeql, pour résider aux côtés de bibliothèques similaires pour tous les autres langages de programmation pris en charge par CodeQL. Les requêtes, les bibliothèques et l’extracteur CodeQL open source pour l’analyse des bases de code écrites en langage de programmation Go avec les outils d’analyse de code CodeQL de GitHub se trouvent désormais dans le nouvel emplacement. Pour plus d’informations, notamment des conseils sur la migration de vos workflows existants, consultez github/codeql-go#741.

Les propriétaires d’entreprise sur des instances avec une licence GitHub Advanced Security peuvent voir une vue d’ensemble des alertes Dependabot pour l’instance entière, y compris une vue centrée sur le référentiel des risques de sécurité des applications, et une vue centrée sur les alertes de toutes les alertes d’analyse des secrets et de Dependabot. Ces vues sont en version bêta et sont susceptibles d’être modifiées. Des vues centrées sur les alertes pour l’analyse du code sont prévues pour une prochaine version de GitHub Enterprise Server. Pour plus d’informations, consultez « Affichage de la vue d’ensemble de la sécurité ».

Les utilisateurs peuvent sélectionner plusieurs alertes Dependabot, puis rejeter ou rouvrir les alertes ou les masquer. Par exemple, dans l’onglet Alertes fermées, vous pouvez sélectionner plusieurs alertes qui ont été précédemment rejetées, puis les rouvrir toutes en même temps. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

• Remarque : Cette fonctionnalité n’est pas disponible dans GitHub Enterprise Server 3.6.0. La fonctionnalité est disponible dans GitHub Enterprise Server 3.7.0 et versions ultérieures. [Mise à jour : 19/10/2022]

Dependabot met à jour les dépendances @types avec les packages correspondants dans les projets TypeScript. Avant ce changement, les utilisateurs pouvaient voir des demandes de tirage distinctes pour un package et le package @types correspondant. Cette fonctionnalité est automatiquement activée pour les référentiels contenant des packages @types dans les devDependencies du projet dans le fichier package.json. Vous pouvez désactiver ce comportement en définissant le champ ignore de votre fichier dependabot.yml sur @types/*. Pour plus d’informations, consultez « À propos des mises à jour de version Dependabot » et « Options de configuration pour le fichier dependabot.yml ».

GitHub Actions peut appliquer des examens de dépendance aux demandes de tirage des utilisateurs en analysant les dépendances, et avertit les utilisateurs des vulnérabilités de sécurité associées. L’action dependency-review-action est soutenue par un nouveau point de terminaison d’API qui différencie les dépendances entre deux révisions. Pour plus d’informations, consultez « À propos de la révision des dépendances ».

Le graphe des dépendances détecte les fichiers Cargo.toml et Cargo.lock pour Rust. Ces fichiers seront affichés dans la section Graphe de dépendances de l’onglet Insights. Les utilisateurs recevront des alertes et des mises à jour de Dependabot pour les vulnérabilités associées à leurs dépendances Rust. Les métadonnées des packages, y compris le mappage des packages aux référentiels, seront ajoutées à une date ultérieure. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Si GitHub Connect est activé pour votre instance, les utilisateurs peuvent contribuer à l’amélioration d’un avis de sécurité dans la Base de données GitHub Advisory. Pour contribuer, cliquez sur Suggérer des améliorations pour cette vulnérabilité en consultant les détails d’un avis. Pour plus d'informations, consultez les articles suivants.

• « Gestion de GitHub Connect »
• « Exploration des vulnérabilités de sécurité dans la base de données GitHub Advisory » dans la documentation GitHub Enterprise Cloud
• « À propos des avis de sécurité GitHub pour les dépôts » dans la documentation GitHub Enterprise Cloud
• « Modification des avis de sécurité dans la base de données GitHub Advisory » dans la documentation GitHub Enterprise Cloud

Dans un workflow qui appelle un workflow réutilisable, les utilisateurs peuvent passer les secrets au workflow réutilisable avec secrets: inherit. Pour plus d’informations, consultez « Réutilisation de workflows ».

Lors de l’utilisation de GitHub Actions, pour réduire le risque de fusionner une modification qui n’a pas été révisée par une autre personne dans une branche protégée, les propriétaires d’entreprise et les administrateurs de référentiel peuvent empêcher Actions de créer des demandes de tirage. Les propriétaires d’organisation pouvaient auparavant activer cette restriction. Pour plus d'informations, consultez les articles suivants.

• « Application de stratégies pour GitHub Actions dans votre entreprise »
• « Désactivation ou limitation de la fonctionnalité GitHub Actions pour votre organisation »
• « Gestion des paramètres de GitHub Actions pour un dépôt »

Les utilisateurs peuvent écrire un workflow unique déclenché par workflow_dispatch et workflow_call, et utiliser le contexte inputs pour accéder aux valeurs d’entrée. Auparavant, les entrées workflow_dispatch se trouvaient dans la charge utile de l’événement, ce qui compliquait le travail des auteurs de workflow qui souhaitaient écrire un workflow à la fois réutilisable et déclenché manuellement. Pour les workflows déclenchés par workflow_dispatch, les entrées sont toujours disponibles dans le contexte github.event.inputs afin de maintenir la compatibilité. Pour plus d’informations, consultez « Contextes ».

Pour résumer le résultat d’un travail, les utilisateurs peuvent générer du Markdown et publier le contenu sous forme de résumé de travail. Par exemple, après avoir exécuté des tests avec GitHub Actions, un résumé peut fournir une vue d’ensemble des tests réussis, échoués ou ignorés, ce qui peut réduire la nécessité d’examiner la sortie complète du journal. Pour plus d’informations, consultez « Commandes de workflow pour GitHub Actions ».

Pour diagnostiquer plus facilement les échecs d’exécution d’un travail lors d’une nouvelle exécution du workflow, les utilisateurs peuvent activer la journalisation de débogage, qui fournit des informations sur l’exécution et l’environnement d’un travail. Pour plus d’informations, consultez « Réexécution des workflows et des travaux » et « Utilisation des journaux d’exécution de workflow ».

Si vous gérez des exécuteurs auto-hébergés pour GitHub Actions, vous pouvez garantir un état cohérent sur l’exécuteur lui-même avant et après l’exécution d’un workflow en définissant des scripts à exécuter. En utilisant des scripts, vous n’avez plus besoin d’exiger que les utilisateurs intègrent manuellement ces étapes dans les workflows. Les scripts pré- et post-travail sont en version bêta et susceptibles d’être modifiés. Pour plus d’informations, consultez « Exécution de scripts avant ou après un travail ».

Les propriétaires d’entreprise peuvent migrer les images de conteneurs du registre GitHub Docker vers le registre de conteneurs GitHub. Le registre de conteneurs offre les avantages suivants.

• Améliore le partage des conteneurs au sein d’une organisation
• Permet l’application d’autorisations d’accès granulaires
• Permet le partage anonyme d’images de conteneurs publics
• Mise en œuvre des normes OCI pour l’hébergement des images Docker

Le registre des conteneurs est en version bêta et susceptible d’être modifié. Pour plus d’informations, consultez « Migration de votre entreprise vers le registre de conteneurs à partir du registre Docker ».

GitHub Discussions est disponible pour GitHub Enterprise Server. GitHub Discussions offre un espace de rassemblement central pour poser des questions, partager des idées et créer des liens. Pour plus d’informations, consultez « Discussions GitHub »

Les propriétaires d’entreprise peuvent configurer une stratégie pour contrôler si les noms d’utilisateur ou les noms complets des personnes sont affichés dans les référentiels internes ou publics. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise ».

Les utilisateurs peuvent créer des fichiers README réservés aux membres d’une organisation. Pour plus d’informations, consultez « Personnalisation du profil de votre organisation ».

Les propriétaires d’organisation peuvent épingler un référentiel au profil d’une organisation directement à partir du référentiel via le nouveau menu déroulant Épingler le référentiel. Les référentiels publics épinglés apparaissent à tous les utilisateurs de votre instance, tandis que les référentiels publics, privés et internes ne sont visibles que par les membres de l’organisation.

Lors de la création d’une duplication, les utilisateurs peuvent personnaliser le nom de la duplication. Pour plus d’informations, consultez « Dupliquer (fork) un dépôt ».

Les utilisateurs peuvent supprimer une branche qui est associée à une demande de tirage ouverte. Pour plus d’informations, consultez « Création et suppression de branches dans votre dépôt ».

Les référentiels ayant plusieurs licences affichent toutes les licences dans la barre latérale « À propos » de l’onglet Code . Pour plus d’informations, consultez la rubrique « Gestion des licences d’un référentiel ».

Les utilisateurs peuvent exiger un déploiement réussi d’une branche avant que quiconque puisse fusionner la demande de tirage associée à la branche. Pour plus d’informations, consultez « À propos des branches protégées » et « Gestion d’une règle de protection de branche ».

Les propriétaires d’entreprise peuvent empêcher les propriétaires d’organisation d’inviter des collaborateurs aux référentiels de l’instance. Pour plus d’informations, consultez « Application d’une stratégie pour inviter des collaborateurs à des dépôts ».

Les utilisateurs peuvent accorder des exceptions à GitHub Apps pour toute règle de protection des branches qui prend en charge les exceptions. Pour plus d’informations, consultez « À propos des applications » et « Gestion d’une règle de protection de branche ».

Pour les clés de signature GPG publiques qui sont expirées ou révoquées, GitHub Enterprise Server vérifie les signatures de validation Git et affiche les validations comme vérifiées si l’utilisateur a effectué la validation alors que la clé était encore valide. Les utilisateurs peuvent également charger des clés GPG expirées ou révoquées. Pour plus d’informations, consultez « À propos de la vérification des signatures de commit ».

Afin d’affirmer qu’une validation est conforme aux règles et aux licences régissant un référentiel, les propriétaires d’organisation et les administrateurs de référentiel peuvent désormais demander aux développeurs de signer les validations effectués via l’interface web. Pour plus d’informations, consultez « Gestion de la stratégie de validation de commits pour votre organisation » et « Gestion de la stratégie de validation de commits pour votre dépôt ».

En utilisant l’arborescence des fichiers située dans l’onglet Fichiers modifiés d’une demande de tirage, les utilisateurs peuvent naviguer dans les fichiers modifiés, comprendre la taille et la portée des changements, et cibler les révisions. L’arborescence des fichiers apparaît si une demande de tirage modifie au moins deux fichiers, et si la fenêtre du navigateur est suffisamment large. Pour plus d’informations, consultez « Révision des changements proposés dans une demande de tirage » et « Filtrage des fichiers dans une demande de tirage ».

Les utilisateurs peuvent utiliser par défaut les titres des demandes de tirage comme message de validation pour toutes les fusions Squash. Pour plus d’informations, consultez « Configuration du squashing de commit pour les demandes de tirage ».

Dans GitHub Mobile pour iOS 1.80.0 et versions ultérieures, les utilisateurs peuvent modifier des fichiers dans la branche de rubrique d’une demande de tirage. La prise en charge de la modification de fichiers sera prise en charge sur GitHub Mobile pour Android dans une version ultérieure. [Mise à jour : 13/09/2022]

En consultant les détails d’une version particulière, les utilisateurs peuvent voir la date de création de chaque ressource de la version. Pour plus d’informations, consultez Affichage des mises en production et étiquettes de votre référentiel. »

Lors de la création d’une version avec des notes de version générées automatiquement, les utilisateurs peuvent voir la balise identifiée comme la version précédente, puis choisir de sélectionner une balise différente à spécifier comme la version précédente. Pour plus d’informations, consultez « Notes de publication générées automatiquement ».

L’édition de Markdown dans l’interface web a été améliorée.

• Lorsqu’un utilisateur sélectionne du texte et colle une URL, le texte sélectionné devient un lien Markdown vers l’URL collée.
• Lorsqu’un utilisateur colle des cellules de tableur ou des tableaux HTML, le texte résultant sera rendu sous forme de tableau.
• Lorsqu’un utilisateur copie un texte contenant des liens, le texte collé inclura le lien sous forme de lien Markdown.

Pour plus d’informations, consultez « Syntaxe de base pour l’écriture et la mise en forme  ».

Lors de l’édition d’un fichier Markdown dans l’interface web, le fait de cliquer sur l’onglet Aperçu fera automatiquement défiler l’écran jusqu’à l’endroit de l’aperçu que vous étiez en train d’éditer. L’emplacement du défilement est basé sur la position de votre curseur avant que vous cliquiez sur l’onglet Aperçu.

Le protocole Git non chiffré et non authentifié est désormais désactivé par défaut. Si vous ne réactivez pas le protocole après la mise à niveau vers GitHub Enterprise Server 3.6 ou ultérieur, les connexions git:// sur le port 9418 retournent l’erreur suivante.

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

Si vous souhaitez prendre en charge le protocole dans votre environnement, vous devez réactiver manuellement la fonctionnalité. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise » et le blog GitHub. [Mise à jour : 31/01/2023]

Les éléments interactifs de l’interface web, comme les liens et les boutons, affichent un contour visible lorsqu’ils sont ciblés par le clavier, afin d’aider les utilisateurs à trouver leur position actuelle sur une page. En outre, lorsqu’ils sont mis en évidence, les champs de formulaire ont un contour plus contrasté.

Si un utilisateur actualise la page lors de la création d’un nouveau problème ou d’une demande de tirage, les personnes désignées, les réviseurs, les balises et les projets seront tous préservés.

L’hyperviseur VMware vSphere ESXi version 7.0 est désormais pris en charge. [Mise à jour : 07/09/2022]

Sur une instance GitHub Enterprise Server qui vient d’être configurée sans aucun utilisateur, un attaquant pourrait créer le premier utilisateur administrateur.

Les règles de pare-feu personnalisées sont supprimées pendant le processus de mise à niveau.

Les fichiers suivis Git LFS chargés via l’interface web sont ajoutés directement au dépôt de manière incorrecte.

Les problèmes ne peuvent pas être fermés s’ils contiennent un permalien vers un blob dans le même dépôt, où le chemin de fichier du blob a plus de 255 caractères.

Lorsque l’option « Les utilisateurs peuvent rechercher sur GitHub.com » est activée avec GitHub Connect, les problèmes dans les dépôts privés et internes ne sont pas inclus dans les résultats de la recherche sur GitHub.com.

Le registre npm GitHub Packages ne retourne plus une valeur de temps dans les réponses de métadonnées. Cela a été fait pour améliorer de manière substantielles les performances. Nous disposons toujours de toutes les données nécessaires pour retourner une valeur de temps dans le cadre de la réponse aux métadonnées et nous rétablirons le retour de cette valeur une fois que nous aurons résolu les problèmes de performance existants.

Les limites de ressources spécifiques au traitement des hooks de pré-réception peuvent entraîner l’échec de certains hooks de pré-réception.

Les services Actions doivent être redémarrés après avoir restauré une instance à partir d’une sauvegarde effectuée sur un hôte différent.

Dans les paramètres d’un référentiel, l’activation de l’option permettant aux utilisateurs ayant un accès en lecture de créer des discussions n’active pas cette fonctionnalité.

Dans certains cas, les utilisateurs ne peuvent pas convertir les questions existantes en discussions.

Les modèles personnalisés pour l’analyse des secrets ont .* comme délimiteur de fin, en particulier dans le champ « Après le secret ». Ce délimiteur provoque des incohérences dans les analyses des secrets entre les référentiels, et vous pourriez remarquer des trous dans l’historique d’un référentiel où aucune recherche n’a été effectuée. Les analyses incrémentielles peuvent également être affectées. Pour éviter les problèmes d’analyse, modifiez la fin du modèle pour supprimer le délimiteur .*.

Dans certains cas, les clients GitHub Advanced Security qui effectuent une mise à niveau vers GitHub Enterprise Server 3.6 peuvent remarquer que les alertes issues de l’analyse des secrets sont absentes de l’interface utilisateur web et l’API REST. Pour vous assurer que les alertes restent visibles, n’ignorez pas la version 3.4 lorsque vous effectuez une mise à niveau vers la dernière version. Pour planifier une mise à niveau via la version 3.4, consultez l’Assistant Mise à niveau.

• Pour afficher les alertes manquantes pour tous les référentiels appartenant à une organisation, les propriétaires d’une organisation peuvent accéder aux paramètres Sécurité et analyse du code de l’organisation, puis cliquer sur Activer tout pour l’analyse secrète. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre organisation ».
• Pour afficher les alertes manquantes pour un référentiel individuel, les personnes disposant d’un accès administrateur au référentiel peuvent désactiver, puis activer l’analyse secrète pour le référentiel. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre dépôt ».

Un correctif est disponible dans la version de patch 3.6.1. [Mise à jour : 01/09/2022]

Après la mise à niveau d’un nœud réplica vers GitHub Enterprise Server 3.6.0 ou version ultérieure et le redémarrage de la réplication, la réplication Git pouvait cesser de progresser et continuer à afficher WARNING: git replication is behind the primary …. Si vous rencontrez ce problème connu, contactez Support GitHub Enterprise. [Mise à jour : 03/10/2022]

Les builds de GitHub Pages peuvent expirer sur des instances dans AWS qui sont configurées pour la haute disponibilité. [Mise à jour : 28/11/2022]

Les instances qui rencontrent un nombre élevé de demandes Git simultanées peuvent être confrontées à des problèmes de performances. Si vous pensez que ce problème affecte votre instance, contactez Support GitHub. Pour plus d’informations, consultez « Création d’un ticket de support ». [Mise à jour : 07/12/2022]

Pour les participants à la version bêta privée de SCIM pour GitHub Enterprise Server, les mappages personnalisés pour les attributs utilisateur SAML ne sont pas pris en charge dans cette version. Les mappages personnalisés sont pris en charge dans GitHub Enterprise Server 3.6.5 ou 3.7.5 et versions ultérieures. [Mise à jour : 27/02/2023]