Enterprise Server 3.7 release notes

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

MOYENNE : Mise à jour de Git pour inclure les correctifs de la version 2.40.1. Pour plus d’informations, consultez Annonces des vulnérabilités de sécurité Git sur le blog GitHub.

Les utilisateurs ne pouvaient pas charger des fichiers GIF en tant que pièces jointes dans un commentaire de problème ou de demande de tirage.

Sur une instance dans une configuration de haute disponibilité, une opération git push pouvait échouer si GitHub Enterprise Server créait simultanément le dépôt sur un nœud de réplica.

L’administrateur de site ne pouvait pas contourner un proxy pour un domaine de premier niveau (TLD) de la liste d’exceptions de l’instance ou des domaines de premier niveau inscrits à l’IANA.

Sur certaines plateformes, une fois qu’une personne avec un accès SSH administratif exécutait ghe-diagnostics, la sortie de la commande incluait une erreur SG_IO esthétique.

Dans certains cas, sur une instance avec une licence GitHub Advanced Security, les utilisateurs n’ont pas pu charger la page d’analyse de sécurité et ont vu une erreur 500.

Lorsqu’un administrateur de site utilisait GitHub Enterprise Importer pour importer des données à partir de GitHub Enterprise Cloud, les migrations échouaient lors de l’importation des commentaires de niveau fichier. Cet échec n’empêche plus l’importation de continuer.

Sur une instance avec une licence GitHub Advanced Security, les utilisateurs avec le rôle de gestionnaire de sécurité pour une organisation ne pouvaient pas afficher les paramètres GitHub Advanced Security de l’organisation.

Si un utilisateur cliquait sur le lien pour partager des commentaires ou signaler des bogues pour la version bêta des listes d’utilisateurs, l’interface web répondait avec une erreur 404.

Lorsqu’un administrateur de site utilisait GitHub Enterprise Importer, l’importation d’un dépôt échouait si une colonne de projet dans le dépôt contenait 2 500 cartes archivées ou plus.

Sur une instance avec les alertes Dependabot activées, les alertes étaient masquées à tort lorsque différentes vulnérabilités étaient détectées par plusieurs détecteurs de soumission au moment de la build.

GitHub Enterprise Server publiait des métriques de distribution qui ne peuvent pas être traitées par collectd. Les métriques étaient pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids et git.hooks.runtime.

Dans certains cas, sur une instance avec GitHub Actions activé, le déploiement du site GitHub Pages à l’aide d’un workflow GitHub Actions échouait avec l’état deployment_lost.

Sur une instance avec une licence GitHub Advanced Security qui avait également été configurée pour un fuseau horaire ultérieur à UTC, la liste des alertes d’analyse des secrets affichait une erreur « Échec du chargement des secrets » si l’utilisateur triait les secrets par date dans l’ordre décroissant.

Sur une instance avec le graphe des dépendances activé, les services en arrière-plan peuvent gérer davantage de trafic.

Les personnes avec un accès SSH administratif qui génèrent un bundle de support à l’aide des utilitaires ghe-support-bundle ou ghe-cluster-support-bundle peuvent spécifier la période pendant laquelle collecter des données avec -p ou --period sans utiliser d’espaces ou de guillemets. Par exemple, en plus de '-p 5 days' ou de -p '4 days 10 hours', -p 5days ou -p 4days10hours sont valides.

Sur une instance avec GitHub Actions activé, les appels imbriqués destinés aux workflows réutilisables au sein d’un travail de workflow réutilisable avec une matrice évaluent correctement les contextes dans les expressions, comme strategy: ${{ inputs.strategies }}.

Les demandes de téléchargement pour des objets Git LFS ne se sont pas terminées tant que la taille de téléchargement finale n’a pas été signalée, ce qui a affecté la latence de ces requêtes, en particulier sur une instance avec des nœuds fonctionnant comme des caches de référentiel.

Pour les instances avec GitHub Connect et l’accès automatique aux actions GitHub.com activés, Dependabot ne parvient pas à mettre à jour les actions hébergées sur GitHub.com.

Dans certains cas, sur une instance avec une licence GitHub Advanced Security, les utilisateurs n’ont pas pu charger la page d’analyse de sécurité et ont vu une erreur 500.

Sur une instance avec GitHub Connect activé, si « Les utilisateurs peuvent rechercher dans GitHub.com » était activé, les problèmes des référentiels privés et internes n’étaient pas inclus dans les résultats de recherche des utilisateurs de GitHub.com.

Après la restauration d’une organisation supprimée, l’organisation n’apparaissait pas dans la liste des organisations de l’instance.

La taille des journaux collectés pouvait augmenter rapidement en raison de l’inclusion de métriques kredz.*, qui ne peuvent pas être analysées par StatsD et entraînaient des messages d’erreur.

Suppression des mesures 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.

Si un administrateur de site fournit une configuration non valide pour le stockage blob pour GitHub Actions ou des packages GitHub sur une instance, la page de vérifications préalables affiche des détails et des informations de résolution des problèmes.

ÉLEVÉE : Résolution d’une vulnérabilité d’authentification incorrecte qui permettait à un acteur non autorisé de modifier les Gists de secrets des autres utilisateurs en s’authentifiant par le biais d’une autorité de certification SSH. Cette vulnérabilité a été signalée via le  programme GitHub Bug Bounty  et porte le numéro  CVE-2023-23761. [Mise à jour : 07/04/2023]

MOYENNE : Résolution d’une vulnérabilité de comparaison incorrecte qui autorisait le trafic de commits en affichant un diff incorrect. Cette vulnérabilité a été signalée via le  programme GitHub Bug Bounty  et porte le numéro  CVE-2023-23762. [Mise à jour : 07/04/2023]

Sur une instance avec GitHub Actions activé, les appels imbriqués destinés aux workflows réutilisables au sein d’un travail de workflow réutilisable avec une matrice évaluent correctement les contextes dans les expressions, comme strategy: ${{ inputs.strategies }}.

Sur une instance dans une configuration de haute disponibilité, une opération git push pouvait échouer si GitHub Enterprise Server créait simultanément le dépôt sur un nœud de réplica.

Dans le tableau de bord du moniteur de la console de gestion, les graphes Cached Requests et Served Requests, qui sont récupérés par la commande git fetch catching, n’affichaient pas de métriques pour l’instance.

Quand un administrateur de site exemptait l’utilisateur @github-actions[bot] de limitation de débit en utilisant la commande ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]", l’exécution de ghe-config-check provoquait l’affichage d’un avertissement Validation is-valid-characterset failed.

GitHub Actions (actions) et Microsoft SQL (mssql) n’apparaissaient pas dans la liste des processus dans le tableau de bord du moniteur des instances.

Dans certains cas, les graphes dans le tableau de bord du moniteur de la console de gestion ne s’affichaient pas.

Sur une instance dans une configuration de haute disponibilité, si un administrateur désactivait la réplication à partir d’un nœud de réplica en utilisant ghe-repl-teardown immédiatement après l’exécution de ghe-repl-setup, mais avant ghe-repl-start, une erreur indiquait que le script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown affiche maintenant une alerte d’information et continue la désactivation.

Quand un administrateur utilisait le point de terminaison d’API REST /setup/api/start pour charger une licence, l’exécution de la configuration échouait avec une erreur Connection refused pendant la phase de migration.

Sur une instance dans une configuration de cluster, quand un administrateur de site définissait le mode de maintenance avec ghe-maintenance -s, une erreur Permission denied se produisait quand l’utilitaire tentait d’accéder à /data/user/common/cluster.conf.

Pendant la configuration de la haute disponibilité, si un administrateur de site interrompait l’utilitaire ghe-repl-start, l’utilitaire signalait par erreur que la réplication était configurée, et l’instance n’effectuait pas les opérations de nettoyage prévues.

Sur les instances configurées pour utiliser la version bêta privée de SCIM pour GitHub Enterprise Server, l’authentification des utilisateurs avec des clés SSH et des jetons d’accès personnels échouait en raison d’une exigence erronée d’autorisation.

Quand un utilisateur importait un dépôt avec la protection des poussées activée, le dépôt n’était pas immédiatement visible dans la vue « Couverture de la sécurité » de la vue d’ensemble de la sécurité.

Les réponses du point de terminaison d’API REST /repositories incluaient par erreur des dépôts supprimés.

Quand un administrateur de site utilisait ghe-migrator pour migrer des données vers GitHub Enterprise Server, dans certains cas, les relations d’équipe imbriquées n’étaient pas conservées après l’importation des équipes.

Si un dépôt contenait un fichier CODEOWNERS avec des annotations de vérification, l’onglet « Fichiers changés » des demandes de tirage renvoyait une erreur 500 et affichait « Une erreur s’est produite » dans la section « Fichiers inchangés avec annotations de vérification ».

Sur une instance avec GitHub Actions activé, si un utilisateur déclenchait manuellement un workflow avec l’API REST, mais ne spécifiait pas de valeurs pour les booléens facultatifs, l’API ne validait pas la demande et renvoyait une erreur 422.

Les rapports CSV pour tous les utilisateurs et tous les utilisateurs actifs, disponibles dans le tableau de bord d’administration du site, ne prenaient pas en compte l’accès récent avec SSH ou des jetons d’accès personnels.

Dans certains cas, sur une instance avec plusieurs nœuds, GitHub Enterprise Server cessait par erreur d’écrire dans les serveurs de fichiers de réplica, ce qui entraînait l’arrêt de la synchronisation des données du dépôt.

GitHub Enterprise Server publiait des métriques de distribution qui ne peuvent pas être traitées par collectd. Les métriques étaient pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids et git.hooks.runtime.

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.

Un propriétaire d’entreprise n’a pas pu activer l’authentification à deux facteurs (TFA) pour une instance si des propriétaires d’entreprise n’avaient pas activé l’authentification à 2 facteurs pour leurs comptes d’utilisateur. [Mise à jour : 17/04/2023]

Quand l’API d’envoi de dépendances reçoit un envoi avec une ou plusieurs dépendances sans version, le graphe des dépendances signale désormais ce fait correctement.

Pour éviter un échec pendant une exécution de configuration sur un cluster, la validation de cluster.conf avec l’utilitaire ghe-cluster-config-check garantit que le champ consul-datacenter de chaque nœud correspond au champ primary-datacenter de niveau supérieur.

Sur une instance dans une configuration de cluster, quand un administrateur de site définit le mode de maintenance sur un seul nœud de cluster en utilisant ghe-maintenance -s, l’utilitaire avertit l’administrateur qu’il doit utiliser ghe-cluster-maintenance -s pour définir le mode de maintenance sur tous les nœuds de cluster. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

Quand un administrateur de site configure un serveur proxy web sortant pour GitHub Enterprise Server, l’instance valide désormais les domaines de niveau supérieur (TLD) exclus de la configuration du proxy. Par défaut, vous pouvez exclure les TLD publics spécifiés par l’IANA. Les administrateurs de site peuvent spécifier une liste de TLD non inscrits à exclure en utilisant ghe-config. Le préfixe . est obligatoire pour tous les TLD publics. Par exemple, .example.com est valide, example.com non. Pour plus d’informations, consultez « Configuration d’un serveur proxy web de trafic sortant ».

Pour éviter les problèmes intermittents liés à la réussite des opérations Git sur une instance avec plusieurs nœuds, GitHub Enterprise Server vérifie l’état du conteneur MySQL avant de tenter une requête SQL. La durée du délai d’expiration a également été réduite.

Le chemin par défaut de la sortie de ghe-saml-mapping-csv -d est /data/user/tmp au lieu de /tmp. Pour plus d’informations, consultez « 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. [Mise à jour : 10/03/2023]

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.

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

ÉLEVÉE : Une vulnérabilité de traversée de chemin a été identifiée dans GitHub Enterprise Server, qui permettait la lecture de fichiers arbitraires 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 porte le numéro CVE-2023-22380.

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.

Pour les instances avec GitHub Connect et l’accès automatique aux actions GitHub.com activés, Dependabot ne parvient pas à mettre à jour les actions hébergées sur GitHub.com.

Le fichier CSV contenant des détails sur les contributeurs GitHub Advanced Security ne pouvait pas être téléchargé si l’instance n’avait pas de licence GitHub Advanced Security.

La taille des journaux collectés pouvait augmenter rapidement en raison de l’inclusion de métriques kredz.*, qui ne peuvent pas être analysées par StatsD et entraînaient des messages d’erreur.

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.

Une fois que l’API REST de soumission de dépendances a reçu une soumission avec une ou plusieurs dépendances sans version, le graphique des dépendances signale ce fait correctement.

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.

Après la désactivation des mises à jour Dependabot, l’avatar de Dependabot s’affichait en tant qu’utilisateur @ghost dans la chronologie d’alerte Dependabot.

Dans certains cas, les utilisateurs peuvent rencontrer une erreur 500 lors de l’affichage de la page des paramètres de Sécurité et analyse du code pour une instance qui présente un nombre très élevé de commiters actifs.

Certains liens permettant de contacter le support GitHub ou d’afficher les notes de publication de GitHub Enterprise Server étaient incorrects.

Le nombre de commiters supplémentaires pour GitHub Advanced Security affichait toujours la valeur 0.

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.

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

Certains services se connectaient de manière incorrecte directement à kafka-lite au lieu de via le proxy interne. Dans un environnement de cluster où les services web et les services de travail s’exécutent sur des nœuds distincts, les messages générés à partir du service de travail Insights n’étaient pas été remis à kafka-lite.

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.

Le tri et le filtrage de la liste des modèles personnalisés pour l’analyse des secrets au niveau de l’organisation ne fonctionnaient pas correctement.

Après la mise à niveau vers GitHub Enterprise Server 3.7, l’affichage de la page des paramètres de sécurité d’une organisation ou d’un dépôt pouvait entraîner une erreur 500 en raison d’un travail de renvoi GitHub Advanced Security ne se terminant pas avant le début de la mise à niveau.

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.

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.

Une condition de concurrence bloquait les mises à niveau vers GitHub Enterprise Server 3.6 ou version ultérieure jusqu’à ce qu’un administrateur de site retente la mise à niveau.

Lorsqu’un administrateur de site exécutait la commande ghe-repl-status sur un réplica de cache via l’interpréteur de commandes d’administration (SSH), la commande signalait de manière incorrecte les informations d’état de réplication globale du cluster 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 à tous les nœuds de réplica disponibles.

Dans une configuration à haute disponibilité, après la promotion d’un réplica comme nœud principal, un administrateur de site ne pouvait pas forcer la réplication à s’arrêter sur un nœud de réplica secondaire à l’aide de la commande ghe-repl-stop -f.

Lors de l’utilisation de la mise en cache de référentiel avec une instance dans une configuration à haute disponibilité, si un client Git utilisait SSH au lieu de HTTPS pour une URL distante de référentiel, Git LFS récupérait les objets du nœud principal 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.

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

L’ajout d’un collaborateur à une duplication (fork) 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.

Le fait de ignorer une alerte Dependabot qui contenait certains caractères pouvait entraîner une erreur 400.

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.

Sur une instance qui utilise SAML pour l’authentification, le menu déroulant Configurer l’authentification unique s’affichait à tort pour les jetons d’accès personnels et les clés SSH.

Une mise à niveau de GitHub Enterprise Server 3.5 vers la version 3.7 pouvait échouer, car l’instance n’avait pas encore vidé les dépôts supprimés.

Dans une configuration de mise en cache de dépôt ou de haute disponibilité, les services Unicorn sur des nœuds autres que le nœud principal ne pouvaient pas envoyer d’événements de journal au nœud principal.

Corrige un bogue à cause duquel un fichier journal GHES pouvait être rempli très rapidement et faire manquer d’espace libre au lecteur racine.

Lors de l’affichage des résultats d’analyse du code pour Ruby, une étiquette bêta erronée apparaissait.

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 de conseil pour garantir les mises à jour horaires à 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]

ÉLEVÉE : Une vulnérabilité au niveau de la neutralisation des délimiteurs d’argument dans une commande a été identifiée dans GitHub Enterprise Server, qui permettait l’exécution de code à distance. Pour exploiter cette vulnérabilité, un attaquant avait besoin de l’autorisation de créer et de générer des pages GitHub avec GitHub Actions. Ce bogue a été signalé à l’origine via le programme Bug Bounty de GitHub et porte le numéro CVE-2022-23740. [Mise à jour : 02/12/2022]

ÉLEVÉE : Une vérification a été ajoutée dans Pages pour s’assurer que le répertoire de travail est propre avant de décompresser le nouveau contenu afin d’éviter un bogue de substitution de fichiers arbitraire. Cette vulnérabilité porte le numéro CVE-2022-46255.

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.

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

L’exécution de la commande ghe-spokesctl a retourné une erreur failed to get repo metrics.

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 sur des nœuds de réplica de cache de dépôt n’étaient pas visibles dans la sortie ghe-repl-status de ces nœuds.

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 entreprenait une action sur l’alerte.

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.

Sur une instance avec des packages GitHub configurés, le chargement et l’installation des packages pouvaient échouer pour les clients utilisant une URL de point de terminaison VPC pour le stockage de blobs AWS S3.

Dans certains cas, après la mise à niveau vers GitHub Enterprise Server 3.7.0, les utilisateurs peuvent rencontrer des erreurs Internal Server Error ou 500 lors du lancement d’opérations Git via SSH ou HTTPS.

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.

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.

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.

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.

Pendant la phase de validation d’une exécution de configuration, une erreur No such object peut se produire pour les services Notebook et Viewscreen. Cette erreur peut être ignorée, car les services devraient toujours démarrer correctement.

À la suite d’une mise à niveau vers GitHub Enterprise Server 3.6 ou ultérieur, les incohérences existantes dans un référentiel, comme des références rompues ou des objets manquants, peuvent maintenant être signalées comme des erreurs, par exemple invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file ou Zero-length loose object file. Auparavant, ces indicateurs d’altération du référentiel pouvaient être ignorés silencieusement. GitHub Enterprise Server utilise désormais une version mise à jour de Git avec des rapports d’erreurs plus consciencieux activés. Pour plus d’informations, consultez ce commit en amont dans le projet Git.

Si vous pensez qu’un problème de ce type existe dans l’un de vos référentiels, contactez le support GitHub Enterprise pour obtenir de l’aide.

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]

Lors de la validation des paramètres de domaine sur une instance avec TLS et l’isolation de sous-domaine activée, la console de gestion n’affiche pas les deux nouveaux sous-domaines http(s)://notebooks.HOSTNAME et http(s)://viewscreen.HOSTNAME de GitHub Enterprise Server 3.7 dans la liste des domaines. [Mise à jour : 12/01/2023]

Sur les instances d’une configuration à haute disponibilité, les opérations git push peuvent échouer dans les situations suivantes. [Mise à jour : 17/03/2023]

• Lors de la création du dépôt sur un nœud de réplica
• Après l’échec de la création du dépôt sur un nœud de réplica, avant la réparation automatique du dépôt

Sur les instances dans une configuration de haute disponibilité, les administrateurs de site doivent uniquement exécuter les commandes ghe-repl-start et ghe-repl-stop lorsque l’instance est en mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance » et « À propos de la configuration de la haute disponibilité ». [Mise à jour : 17/03/2023]

Pour renforcer la sécurité de la console de gestion, les administrateurs de site peuvent configurer la limite de débit pour les tentatives de connexion, ainsi que la durée du verrouillage après le dépassement de la limite de débit. Pour plus d’informations, consultez « Configuration des limites de débit ».

Les exigences minimales de mot de passe pour la console de gestion sont plus strictes.

Les tentatives d’authentification auprès de la console de gestion et les modifications apportées par un administrateur de site au sein de la console de gestion sont écrites dans un fichier journal dans /var/log/enterprise-manage/audit.log.

Azure Maps remplace MapBox pour le rendu des fichiers GeoJSON en tant que cartes visuelles. Les administrateurs peuvent activer le rendu de carte et fournir un jeton Azure Maps dans la console de gestion. Pour plus d’informations, consultez « Administration de votre instance à partir de la console de gestion ».

Les utilisateurs peuvent vérifier les validations à l’aide d’une clé publique SSH. Pour plus d’informations, consultez « À propos de la vérification des signatures de commit ».

Les administrateurs de site peuvent provisionner automatiquement des utilisateurs et des groupes sur une instance GitHub Enterprise Server avec SCIM. SCIM pour GitHub Enterprise Server est en version bêta privée et est susceptible d’être modifié. Pour plus d’informations, consultez « Configuration du provisionnement d’utilisateurs avec SCIM pour votre entreprise » et « SCIM » dans la documentation de l’API REST.

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent afficher et commenter les alertes d’analyse du code dans leur dépôt dans l’onglet Conversation d’une demande de tirage. Si la règle Exiger la résolution de la conversation avant la fusion de la branche est activée pour le dépôt, tous les commentaires sur ces alertes d’analyse de code doivent être résolus avant qu’un utilisateur fusionne la demande de tirage. Pour plus d’informations, consultez « À propos de l’analyse du code », « À propos des révisions de demande de tirage » et « À propos des branches protégées ».

Pour simplifier le déploiement de l’analyse des secrets pour les instances de dizaines, centaines voire milliers d’organisations, les propriétaires d’entreprise sur une instance avec une licence GitHub Advanced Security peuvent activer l’analyse des secrets et la protection push pour l’instance à l’aide de l’interface web. Pour plus d’informations, consultez « Gestion des fonctionnalités de GitHub Advanced Security pour votre entreprise ».

Les propriétaires d’organisation sur une instance avec une licence GitHub Advanced Security peuvent effectuer un test de modèles personnalisés pour l’analyse des secrets pour tous les dépôts au sein d’une organisation. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

Si un administrateur de site a activé les notifications par e-mail pour une instance avec une licence GitHub Advanced Security, les utilisateurs qui surveillent les alertes d’analyse des secrets d’un dépôt recevront une notification par e-mail lorsqu’un contributeur contourne un secret bloqué par la protection push. Auparavant, les notifications n’étaient pas envoyées si le secret était marqué comme faux positif ou utilisé dans des tests. Pour plus d’informations, consultez « Protection des envois push avec l’analyse des secrets » et « Configuration de la messagerie pour les notifications ».

Pour faciliter la gestion de dizaines ou de centaines de modèles personnalisés pour l’analyse des secrets, les utilisateurs, propriétaires d’organisation ou propriétaires d’entreprise d’une instance avec une licence GitHub Advanced Security peuvent trier et filtrer la liste des modèles pour un dépôt, une organisation ou l’instance entière. 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 qui protègent les envois push avec l’analyse des secrets peuvent spécifier un lien personnalisé qui s’affichera dans le message d’erreur lorsque la protection push détecte et bloque un secret potentiel. Pour plus d’informations, consultez « Protection des poussées avec l’analyse des secrets ».

Les utilisateurs peuvent publier des packs CodeQL dans le registre de conteneurs. Pour plus d’informations, consultez Création et utilisation de packs CodeQL dans la documentation de l’interface CLI CodeQL.

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent utiliser des packs CodeQL avec l’analyse du code, y compris les packs publiés dans le registre de conteneurs GitHub de l’instance. Pour plus d’informations, consultez « Configuration de l’analyse du code » et Publication et utilisation de packs CodeQL dans la documentation de l’interface CLI CodeQL.

Les utilisateurs d’une instance avec une licence GitHub Advanced Security peuvent exclure les requêtes CodeQL inutiles pour l’analyse du code à l’aide de filtres de requête. Pour plus d’informations, consultez « Configuration de l’analyse du code ».

Les propriétaires d’entreprise d’une instance avec une licence GitHub Advanced Security peuvent récupérer les résultats d’analyse du code pour l’ensemble de l’instance à l’aide de l’API REST. Le nouveau point de terminaison complète les points de terminaison existants pour les dépôts et les organisations. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

Les propriétaires d’organisation sur une instance avec une licence GitHub Advanced Security peuvent récupérer l’état d’activation ou configurer l’activation automatique des fonctionnalités suivantes à l’aide de l’API REST.

• Sécurité avancée GitHub
• Analyse de secrets
• Protection push.

Pour plus d’informations, consultez « Organisations » dans la documentation de l’API REST.

Les utilisateurs d’une instance disposant d’une licence GitHub Advanced Security peuvent utiliser des curseurs pour paginer les résultats d’alerte d’analyse des secrets récupérés avec les points de terminaison d’organisation et de dépôt de l’API REST. Pour plus d’informations, consultez « Analyse de secrets » dans la documentation de l’API REST.

La vue d’ensemble de la sécurité de l’instance inclut des informations sur Dependabot. Pour plus d’informations, consultez « Affichage de la vue d’ensemble de la sécurité ».

Les utilisateurs peuvent voir plus d’informations sur l’activité associée à une alerte Dependabot. Dans les détails d’une alerte Dependabot, les utilisateurs peuvent voir une chronologie des événements, comme le moment où l’alerte a été ouverte, corrigée ou rouverte. Les événements affichent également des métadonnées supplémentaires lorsqu’elles sont disponibles, comme les demandes de tirage pertinentes. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

Les alertes Dependabot des utilisateurs sont triées par importance par défaut. L’importance considère CVSS comme le facteur principal, ainsi que le risque potentiel, la pertinence et la facilité de résolution de la vulnérabilité. Le calcul s’améliorera au fil du temps.

Les utilisateurs peuvent trier les alertes Dependabot en fonction de l’étendue de la dépendance, runtime ou développement.

Les utilisateurs peuvent éventuellement ajouter un commentaire lors de l’abandon d’une alerte Dependabot. Les commentaires de masquage s’affichent dans la chronologie des événements et dans le champ dismissComment dans l’objet RepositoryVulnerabilityAlert de l’API GraphQL. Pour plus d’informations sur l’API GraphQL, consultez la documentation « Objets ».

Les utilisateurs peuvent sélectionner plusieurs alertes Dependabot, puis rejeter ou rouvrir les alertes. 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.

Les propriétaires d’organisation sur une instance peuvent récupérer l’état d’activation ou configurer l’activation automatique des fonctionnalités suivantes pour la gestion des dépendances à l’aide de l’API REST.

• Graphe de dépendances
• Alertes Dependabot
• Mises à jour de sécurité Dependabot

Pour plus d’informations, consultez « Organisations » dans la documentation de l’API REST.

Les propriétaires d’entreprise, les propriétaires d’organisation et les responsables de la sécurité peuvent accéder à une vue centralisée des risques sur l’ensemble de l’instance. La vue comprend également une vue centrée sur les alertes de toutes les alertes d’analyse du code, d’analyse des secrets et de Dependabot. Les propriétaires d’entreprise peuvent afficher des alertes pour les organisations dont ils sont propriétaires. Les propriétaires d’organisation et gestionnaires de sécurité peuvent afficher les référentiels et les alertes pour les organisations auxquelles ils ont un accès total. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Les propriétaires d’organisation peuvent gérer des équipes de responsables de la sécurité à l’aide de l’API REST. Pour plus d’informations, consultez « Gestionnaires de sécurité » dans la documentation de l’API REST.

Les utilisateurs peuvent tirer parti des améliorations suivantes apportées à la Base de données GitHub Advisory.

• La base de données affiche des avis pour Elixir, le gestionnaire de package Hex d’Erlang, et bien plus encore.
• Les utilisateurs peuvent trouver les avis relatifs aux programmes malveillants en recherchant type:malware.
• La base de données affiche des avis pour les vulnérabilités GitHub Actions.

Pour plus d’informations, consultez « Exploration des avis de sécurité dans la base de données GitHub Advisory. »

Les utilisateurs peuvent remplir le graphe de dépendances d’un dépôt en soumettant les dépendances pour le dépôt à l’aide de l’API REST. Le graphe de dépendances alimente les alertes Dependabot et les mises à jour de sécurité Dependabot. Pour plus d'informations, voir « Utilisation de l’API de soumission de dépendances ».

GitHub Actions prend en charge Google Cloud Storage en tant que fournisseur de stockage pour les journaux, les artefacts et les caches. Pour plus d’informations, consultez « Activation de GitHub Actions avec Google Cloud Storage ».

Les utilisateurs GitHub Actions qui utilisent la mise en cache des dépendances pour accélérer les workflows peuvent désormais utiliser l’interface CLI GitHub pour gérer le cache GitHub Actions d’un dépôt. Pour gérer les caches à l’aide de l’interface CLI GitHub, installez l’extension gh-actions-cache. Pour plus d’informations, consultez la documentation gh-actions-cache.

Le workflow s’exécute à nouveau dans GitHub Actions avec l’acteur qui a initialement déclenché le workflow pour l’évaluation des privilèges. L’acteur qui a déclenché la nouvelle exécution continue d’être affiché dans l’interface utilisateur et est accessible dans un workflow via le champ triggering_actor dans le contexte github. Pour plus d’informations, consultez « Réexécution de workflows et de travaux » et « Contextes ».

Les utilisateurs peuvent appeler des workflows réutilisables à partir d’une matrice ou d’autres workflows réutilisables. Pour plus d’informations, consultez « Réutilisation de workflows ».

Lors de l’interrogation d’artefacts GitHub Actions, l’API REST retourne des informations sur l’exécution et la branche qui ont produit l’artefact. Pour plus d’informations, consultez « Artefacts GitHub Actions » dans la documentation de l’API REST.

Pour prendre en charge des déploiements cloud sécurisés à grande échelle, les propriétaires d’organisation et les administrateurs de dépôt peuvent effectuer les tâches suivantes avec l’API REST OpenID Connect. Pour plus d’informations, consultez GitHub Actions OIDC dans la documentation de l’API REST.

• Activez une configuration OpenID Connect standard sur les workflows de déploiement cloud en personnalisant le format de revendication subject.
• Assurez une conformité et une sécurité supplémentaires pour les déploiements OpenID Connect en ajoutant l’URL issuer au slug de l’entreprise.
• Configurez des stratégies OpenID Connect avancées en utilisant des revendications de jeton OpenID Connect supplémentaires, comme repository_id et repo_visibility.

Pour plus d’informations, consultez « À propos du durcissement de la sécurité avec OpenID Connect ».

Les utilisateurs GitHub Actions qui utilisent la mise en cache des dépendances pour accélérer les workflows peuvent désormais utiliser l’API REST GitHub Actions Cache pour effectuer les tâches suivantes.

• Répertorier tous les caches d’un dépôt et trier par métadonnées.
• Supprimer une entrée de cache endommagée ou obsolète. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows » et « GitHub Actions Cache » dans la documentation de l’API REST.

Si un exécuteur GitHub Actions auto-hébergé non éphémère ne communique pas avec l’instance GitHub Enterprise Server pendant plus de 14 jours, l’instance supprime automatiquement l’exécuteur. Si un exécuteur auto-hébergé éphémère ne communique pas avec l’instance pendant plus d’un jour, l’instance supprime automatiquement l’exécuteur. Auparavant, GitHub Enterprise Server supprimait les exécuteurs après 30 jours. Pour plus d’informations, consultez « About self-hosted runners ».

GitHub Actions peut exécuter des workflows macOS auto-hébergés dans un runtime ARM64 macOS avec prise en charge de l’exécuteur pour les pouces à silicium Apple, comme les modèles M1 ou M2. Pour plus d’informations, consultez « Utilisation d’exécuteurs auto-hébergés dans un workflow ».

Les utilisateurs peuvent déployer un site GitHub Pages directement à partir d’un dépôt à l’aide de GitHub Actions, sans configuration d’une source de publication. L’utilisation de GitHub Actions permet de contrôler l’infrastructure de création et gestion des versions, ainsi que de mieux contrôler le processus de publication avec des fonctionnalités comme les portes de déploiement. Pour plus d’informations, consultez « Configuration d’une source de publication pour votre site GitHub Pages ».

Les propriétaires d’entreprise peuvent empêcher les utilisateurs de créer des dépôts appartenant à leurs comptes d’utilisateur. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise ».

Les propriétaires d’entreprise peuvent contrôler où les utilisateurs peuvent dupliquer les dépôts. La duplication peut être limitée à des combinaisons prédéfinies d’organisations, de la même organisation que le dépôt parent, des comptes d’utilisateur ou n’importe où. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise ».

Les administrateurs de référentiels peuvent bloquer les envois (push) potentiellement destructeurs en limitant le nombre de branches et d’étiquettes qui peuvent être mises à jour par un seul envoi. Par défaut, le nombre de branches et de balises qui peuvent être mises à jour en un seul envoi (push) n’est soumis à aucune limite. Pour plus d’informations, consultez « Gestion de la stratégie d’envoi pour votre dépôt ».

Les utilisateurs peuvent personnaliser davantage le message de validation par défaut lors de la fusion squash d’une demande de tirage. Pour plus d’informations, consultez « Configuration de la fusion des validations pour les demandes de tirage » et « Configuration de la fusion Squash des validations pour les demandes de tirage ».

Les utilisateurs peuvent créer une branche à partir de la page de vue d’ensemble Branches d’un référentiel en cliquant sur le bouton Nouvelle branche. Pour plus d’informations, consultez « Création et suppression de branches dans votre dépôt ».

Lorsqu’un utilisateur renomme ou déplace un fichier dans un nouveau répertoire, si au moins la moitié du contenu du fichier est identique, l’historique des validations indique que le fichier a été renommé, de façon similaire à git log --follow. Pour plus d’informations, consultez le blog API GitHub Packages. [Mise à jour : 10/02/2023]

Des améliorations ont été apportées à la création et à la gestion des duplications.

• Lors de la duplication d’un dépôt, les utilisateurs peuvent choisir d’inclure uniquement la branche par défaut du dépôt dans la duplication.
• Les utilisateurs peuvent utiliser le bouton Dupliquer d’un dépôt pour afficher les duplications existantes du dépôt.
• Le bouton Extraire en amont a été renommé Synchroniser la duplication mieux décrire le comportement du bouton. Si la synchronisation provoque un conflit, l’interface utilisateur web invite l’utilisateur à apporter des modifications au dépôt parent, à ignorer les modifications ou à résoudre le conflit.
• Pour résoudre les situations où des personnes travaillent au sein d’une organisation et ne souhaitent pas dupliquer un dépôt vers une autre organisation ou un autre compte d’utilisateur, les utilisateurs peuvent dupliquer un dépôt vers la même organisation que le dépôt parent.
• Les utilisateurs peuvent dupliquer un dépôt interne vers une autre organisation, et la duplication conserve la visibilité interne. Lors de la duplication d’un dépôt interne, les utilisateurs peuvent choisir l’organisation qui doit être propriétaire de la duplication.

Pour plus d’informations, consultez « Dupliquer (fork) un dépôt ».

Les administrateurs du référentiel peuvent bloquer la création de branches qui correspondent à un modèle de nom configuré avec la règle de protection des branches Restriction des envois qui créent des branches correspondantes. Par exemple, si la branche par défaut d’un référentiel passe de master à main, l’administrateur du référentiel peut empêcher toute création ou tout envoi ultérieur de la branche master. Pour plus d’informations, consultez « À propos des branches protégées » et « Gestion d’une règle de protection de branche ».

Les utilisateurs peuvent créer des fichiers avec des diagrammes geoJSON, topoJSON et STL et afficher les diagrammes dans l’interface web. Pour plus d’informations, consultez « Travailler avec des fichiers non basés sur du code ».

Les utilisateurs peuvent créer des références avec lien automatique à l’aide d’identificateurs alphanumériques ou numériques. Pour plus d’informations, consultez « Configuration des liens automatiques pour référencer des liens automatiques vers des ressources externes ».

Les utilisateurs peuvent personnaliser les exclusions dans la recherche de fichiers comme vendor/ et build/ en utilisant les attributs linguist dans un fichier .gitattributes. Pour plus d’informations, consultez « Recherche de fichiers sur GitHub » et « Personnalisation de l’affichage des fichiers modifiés sur GitHub ».

Les utilisateurs peuvent parcourir les fichiers modifiés dans une validation individuelle à l’aide de l’arborescence. Pour plus d’informations, consultez À propos des commits.

Les utilisateurs peuvent lier manuellement des branches existantes ou des demandes de tirage à un problème à partir de la section « Développement » de la barre latérale du problème. Pour plus d’informations, consultez « Liaison d’une demande de tirage à un problème ».

Les utilisateurs peuvent utiliser la syntaxe Mermaid lors de l’écriture de Markdown, qui affiche un diagramme lors du rendu du Markdown. Pour plus d’informations, consultez « Création de diagrammes ».

Les utilisateurs peuvent écrire des expressions mathématiques à l’aide de blocs de code délimités avec la syntaxe math en plus des délimiteurs existants. $$ n’est pas obligatoire avec cette méthode. Pour plus d’informations, consultez « Écrire des expressions mathématiques ».

• Remarque : Cette fonctionnalité n’est pas disponible dans GitHub Enterprise Server 3.7. La fonctionnalité sera disponible dans une prochaine version. [Mise à jour : 16/11/2022]

Les utilisateurs peuvent afficher des cartes directement dans le Markdown à l’aide de blocs de code délimités avec la syntaxe geojson ou topojson et incorporer des rendus STL 3D à l’aide de la syntaxe stl. Pour plus d’informations, consultez « Création de diagrammes ».

Dans le Markdown, les utilisateurs peuvent écrire une syntaxe de style LaTeX pour afficher des expressions mathématiques inline à l’aide de délimiteurs $, ou dans des blocs en utilisant des délimiteurs $$. Pour plus d’informations, consultez « Écrire des expressions mathématiques ».

Pour améliorer la stabilité, le service de rendu des formats GeoJSON, Jupyter Notebook, PDF, PSD, SVG, SolidWorks et d’autres formats binaires a été remplacé.

Si l’isolation TLS et de sous-domaine est configurée pour votre instance et que votre certificat n’est pas un certificat générique, vous devez générer un nouveau certificat qui inclut les sous-domaines supplémentaires pour ces services, notebooks.HOSTNAME et viewscreen.HOSTNAME. Pour plus d’informations, consultez « Activation de l’isolation de sous-domaine ». [Mise à jour : 02/12/2022]

L’analyse des secrets ne prend plus en charge les modèles personnalisés qui utilisent .* comme délimiteur de fin dans le champ « Après le secret », car la syntaxe du modèle entraînait des problèmes d’analyse et des incohérences.

Lors de la création d’une version, les utilisateurs peuvent désormais envoyer le formulaire en utilisant Ctrl + Entrée dans macOS ou Ctrl + Entrée dans Windows ou Linux.

L’onglet Wiki dans un dépôt s’affiche uniquement lorsqu’un wiki existe. Auparavant, l’onglet apparaissait toujours.

Les wikis rendus affichent des expressions mathématiques et des diagrammes Mermaid.

La taille du champ de recherche pour les journaux d’audit des utilisateurs, de l’organisation et de l’entreprise a augmenté.

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.

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.

Pendant la phase de validation d’une exécution de configuration, une erreur No such object peut se produire pour les services Notebook et Viewscreen. Cette erreur peut être ignorée, car les services devraient toujours démarrer correctement.

Dans certains cas, après la mise à niveau vers GitHub Enterprise Server 3.7.0, les utilisateurs peuvent rencontrer des erreurs Internal Server Error ou 500 lors du lancement d’opérations git via SSH ou HTTPS. Exemple :

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

Si vous rencontrez ces problèmes, contactez le support GitHub Enterprise avec un bundle de support. La solution de contournement temporaire connue à ce stade consiste à redémarrer le service github-gitauth avec les commandes ci-dessous :

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

Nous étudions actuellement un correctif permanent pour un prochain correctif à chaud [Mise à jour : 24-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]

Lors de la validation des paramètres de domaine sur une instance avec TLS et l’isolation de sous-domaine activée, la console de gestion n’affiche pas les deux nouveaux sous-domaines http(s)://notebooks.HOSTNAME et http(s)://viewscreen.HOSTNAME de GitHub Enterprise Server 3.7 dans la liste des domaines. [Mise à jour : 12/01/2023]

Sur les instances d’une configuration à haute disponibilité, les opérations git push peuvent échouer dans les situations suivantes. [Mise à jour : 17/03/2023]

• Lors de la création du dépôt sur un nœud de réplica
• Après l’échec de la création du dépôt sur un nœud de réplica, avant la réparation automatique du dépôt

Sur les instances dans une configuration de haute disponibilité, les administrateurs de site doivent uniquement exécuter les commandes ghe-repl-start et ghe-repl-stop lorsque l’instance est en mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance » et « À propos de la configuration de la haute disponibilité ». [Mise à jour : 17/03/2023]