Enterprise Server 3.8 release notes

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.

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.

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.

Sur une instance avec un grand nombre d’organisations, les propriétaires d’entreprise qui accédaient à la page des paramètres « Sécurité et analyse » de l’entreprise pouvaient retourner une erreur 500.

À partir de GitHub Enterprise Server 3.8, l’utilisation de l’interface CLI GitHub Enterprise Importer, de l’API startRepositoryMigration GraphQL ou de l’API REST « Démarrer une migration d’organisation » nécessite la configuration d’un fournisseur de stockage de blob dans la console de gestion. Lors de l’utilisation du Stockage Blob Azure, les conteneurs de stockage étaient mal configurés pour être accessibles publiquement. Les conteneurs du Stockage Blob Azure sont désormais configurés pour être privés, et nous avons introduit une vérification qui fait échouer explicitement les exportations si le conteneur de stockage est public.

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.

Dans certains cas sur une instance avec plusieurs nœuds, la réplication Git n’arrivait pas à répliquer entièrement les dépôts qui avaient été supprimés, ce qui entraînait un avertissement dans la sortie ghe-repl-status.

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 une licence GitHub Advanced Security où l’analyse des secrets est activée, une journalisation excessive dans /var/log peut entraîner des erreurs qui s’affichent aux utilisateurs et dégrader les performances système si les journaux ont consommé tout l’espace libre sur le volume.

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.

Une fois qu’un administrateur de site exporte une archive de migration à l’aide de l’utilitaire gh-migrator GitHub Enterprise Importers, le lien vers l’archive reste accessible pendant 48 heures au lieu d’une heure.

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.

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.

Lorsqu’un administrateur de site exécutait ghe-btop via SSH, la commande n’a pas été exécutée et une erreur /usr/bin/env: python3: No such file or directory s’est produite.

Les administrateurs de site qui se préparaient à activer GitHub Actions n’ont pas pu exécuter l’utilitaire ghe-actions-precheck, car le fichier de scripts n’était pas exécutable.

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.

Une fois qu’un administrateur de site a exporté une archive de migration vers AWS S3 à l’aide de l’utilitaire GitHub Enterprise gh-migrator de Importer, l’URL de l’archive était inaccessible.

Si un administrateur de site exportait une archive de migration vers un compartiment dans la région AWS S3s us-east-1 à l’aide de l’utilitaire GitHub Enterprise gh-migrator de Importer, l’archive était inaccessible.

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.

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.

Une fois qu’un administrateur de site exporte une archive de migration à l’aide de l’utilitaire GitHub Enterprise gh-migrator de Importer, le lien vers l’archive reste accessible pendant 48 heures au lieu d’une heure.

Sur une instance avec une licence GitHub Advanced Security, les utilisateurs qui créent des modèles personnalisés pour l’analyse des secrets peuvent fournir des expressions (devant ou non correspondre) de 2 000 caractères maximum. Cette limite a été augmentée de 1 000 caractères.

É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é, un travail de workflow pour GitHub Actions ne démarrait pas si un groupe d’exécuteurs correspondant n’était pas disponible au moment de la mise en file d’attente initiale du travail, même si un groupe d’exécuteurs correspondant était devenu disponible après l’entrée du travail dans la file d’attente.

Sur une instance avec GitHub Actions activé, GitHub Actions s’exécute désormais correctement après la restauration d’un dépôt supprimé.

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

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

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.

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.

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.

Les commandes exécutées par les administrateurs de site via SSH sur l’un des nœuds d’instance n’étaient pas journalisées dans /var/log/ssh-console-audit.log.

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.

Quand les utilisateurs recherchaient des gists, le texte dans le champ de recherche n’était pas visible dans certains cas, car la couleur du texte était identique à la couleur d’arrière-plan des champs.

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.

Sur une instance avec GitHub Connect activé, si « Les utilisateurs peuvent rechercher dans GitHub.com » était activé, les utilisateurs ne pouvaient pas voir les problèmes des dépôts privés et internes dans les résultats de recherche de GitHub.com.

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

Sur une instance avec une licence GitHub Advanced Security, les utilisateurs qui créent des modèles personnalisés pour l’analyse des secrets peuvent fournir des expressions (devant ou non correspondre) de 2 000 caractères maximum. Cette limite a été augmentée de 1 000 caractères.

Projects, l’outil flexible de planification et de suivi du travail sur GitHub Enterprise Server, est désormais disponible en version bêta. Un projet est une feuille de calcul adaptable qui intègre problèmes et demandes de tirage pour aider les utilisateurs à planifier et à suivre efficacement le travail. Les utilisateurs peuvent créer et personnaliser plusieurs vues, et chaque vue peut filtrer, trier et regrouper les problèmes et les demandes de tirage. Les utilisateurs peuvent également définir des champs personnalisés pour suivre les métadonnées uniques d’une équipe ou d’un projet, ce qui permet d’avoir une personnalisation pour tout besoin ou processus. Cette fonctionnalité est susceptible d’être modifiée. Pour plus d’informations, consultez « À propos des Projects (beta) ».

Les administrateurs de site peuvent améliorer la sécurité d’une instance en créant des comptes d’utilisateur dédiés pour la console de gestion. Seul l’administrateur de site racine peut créer des comptes d’utilisateur. Pour contrôler l’accès aux comptes d’utilisateur, attribuez le rôle d’éditeur ou d’opérateur. Les opérateurs peuvent gérer l’accès SSH administratif pour l’instance. Pour plus d’informations, consultez « Gestion de l’accès à la console de gestion ».

Pour établir ou se conformer à des stratégies internes, les administrateurs de site peuvent utiliser la console de gestion afin de configurer la stratégie d’une instance pour la conservation des données liées aux vérifications, notamment les données de vérification générées par GitHub Actions et l’API États. Les administrateurs peuvent activer ou désactiver la conservation, définir un seuil de conservation personnalisé ou définir un seuil de suppression définitive personnalisé. Pour plus d’informations, consultez « Configuration des applications » [Mise à jour : 02/03/2023]

Lors de la génération de bundles de support avec l’utilitaire en ligne de commande ghe-support-bundle, les administrateurs de site peuvent spécifier la durée exacte à utiliser pour la collecte de données dans le bundle. Pour plus d’informations, consultez « Utilitaires en ligne de commande ».

Les utilisateurs peuvent réviser et révoquer les sessions de navigateur et GitHub Mobile pour une instance GitHub Enterprise Server. Pour plus d’informations, consultez « Visualisation et gestion de vos sessions ».

Les propriétaires d’entreprise peuvent configurer si les administrateurs de dépôt peuvent activer ou désactiver les alertes Dependabot. Sur les instances avec une licence GitHub Advanced Security, les propriétaires d’entreprise peuvent également définir des stratégies pour contrôler si les administrateurs de dépôt peuvent activer les fonctionnalités GitHub Advanced Security ou l’analyse des secrets. Pour plus d’informations, consultez « Application de stratégies de sécurité et d’analyse du code pour votre entreprise ».

Les propriétaires d’entreprise et d’organisation peuvent prendre en charge l’adhérence au principe de privilège minimum en accordant l’accès aux points de terminaison de journal d’audit sans fournir de privilèges d’administration complets. Pour fournir cet accès, les jetons d’accès personnels et les applications OAuth prennent désormais en charge l’étendue read:audit_log. Pour plus d’informations, consultez « Utilisation de l’API de journal d’audit pour votre entreprise ».

Les propriétaires d’entreprise peuvent plus facilement détecter et suivre l’activité associée aux jetons d’authentification en consultant les données de jeton dans les événements de journal d’audit. Pour plus d’informations, consultez « Identification des événements de journal d’audit effectués par un jeton d’accès ».

Les propriétaires d’entreprise peuvent configurer le streaming de journaux d’audit sur un point de terminaison Datadog. Pour plus d’informations, consultez « Streaming de journaux d’audit pour votre entreprise ».

Les propriétaires d’entreprise d’une instance avec une licence GitHub Advanced Security peuvent voir les modifications apportées à GitHub Advanced Security, à l’analyse des secrets et à l’activation de la protection des poussées dans le journal d’audit. Les propriétaires d’organisation peuvent voir les modifications apportées aux messages personnalisés pour la protection des poussées dans le journal d’audit. Pour plus d’informations, consultez la documentation suivante.

• « Actions de catégorie business_secret_scanning », « Actions de catégorie business_secret_scanning_push_protection » et « Actions de catégorie business_secret_scanning_push_protection_custom_message » dans « Événements de journal d’audit pour votre entreprise »
• « Examen du journal d’audit de votre organisation »

Les propriétaires d’entreprise sur une instance avec une licence GitHub Advanced Security peuvent garantir la conformité et simplifier le déploiement de l’analyse des secrets et de la protection des poussées de toutes les organisations sur l’instance à l’aide de l’API REST. Ce point de terminaison vient compléter l’interface utilisateur web existante et les points de terminaison pour les dépôts et les organisations. Pour plus d’informations, consultez « Sécurité et analyse du code » dans la documentation de l’API REST.

Les propriétaires d’entreprise et d’organisation qui utilisent l’analyse des secrets sur une instance avec une licence GitHub Advanced Security peuvent utiliser l’API REST pour spécifier un lien personnalisé à afficher lorsque la protection des poussées bloque une poussée contenant un secret. Pour plus d’informations, consultez « Sécurité et analyse du code » ou « Organisations » dans la documentation de l’API REST.

Les utilisateurs d’une instance avec une licence GitHub Advanced Security qui ignorent une alerte d’analyse des secrets peuvent aider les autres utilisateurs à en comprendre la raison en fournissant un commentaire facultatif à l’aide de l’interface utilisateur web ou de l’API REST. Pour plus d’informations, consultez la documentation suivante.

• « Gestion des alertes de l’analyse des secrets »
• « Analyse des secrets » dans la documentation de l’API REST

Les utilisateurs d’une instance avec une licence GitHub Advanced Security peuvent filtrer les résultats de l’API Analyse du code en fonction de la gravité des alertes au niveau du dépôt ou de l’organisation. Utilisez le paramètre severity pour retourner uniquement les alertes d’analyse du code avec une gravité spécifique. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

Les utilisateurs d’une instance avec une licence GitHub Advanced Security peuvent analyser deux langages supplémentaires pour détecter les vulnérabilités et les erreurs à l’aide de l’analyse du code CodeQL. La prise en charge de Ruby est en disponibilité générale, tandis que la prise en charge de Kotlin est en version bêta et susceptible d’être modifiée.

• L’analyse Ruby peut détecter plus de deux fois le nombre de faiblesses courantes qu’elle ne pouvait en détecter en version bêta. Au total, 30 règles peuvent identifier un éventail de vulnérabilités, notamment le scripting inter-site (XSS), le déni de service d’expression régulière (ReDoS), l’injection de code SQL, etc. La couverture de bibliothèques et de frameworks supplémentaires pour Ruby-on-Rails offre aux développeurs de services web la garantie d’obtenir des résultats encore plus précis. GitHub Enterprise Server prend en charge toutes les versions courantes de Ruby, jusqu’à la version 3.1 comprise.
• La prise en charge de Kotlin est une extension de la prise en charge de Java existante et bénéficie des requêtes CodeQL existantes pour Java, qui s’appliquent aux applications mobiles et côté serveur. GitHub a également amélioré et ajouté une gamme de requêtes spécifiques aux mobiles, couvrant des problèmes tels que la gestion des intentions, les problèmes de validation de vue web, l’injection de fragments, etc.

Pour plus d’informations sur l’analyse du code, consultez « À propos de l’analyse du code avec CodeQL ».

Les utilisateurs d’une instance avec une licence GitHub Advanced Security qui utilisent l’analyse du code CodeQL peuvent personnaliser la configuration de build pour l’analyse Go dans le fichier de workflow GitHub Actions. Les workflows CodeQL existants pour l’analyse Go ne nécessitent aucune modification et continueront d’être pris en charge. Pour plus d’informations, consultez « Configuration du workflow CodeQL pour les langages compilés ».

Pour améliorer la sécurité du code et simplifier le processus de mise à jour des dépendances vulnérables, davantage d’utilisateurs peuvent recevoir des demandes de tirage automatiques avec mises à jour des dépendances.

• Les auteurs GitHub Actions peuvent mettre à jour automatiquement les dépendances dans les fichiers de workflow.
• Les développeurs Dart ou Flutter qui utilisent Pub peuvent mettre à jour automatiquement les dépendances au sein de leurs projets.

Pour plus d’informations, consultez « À propos des mises à jour de sécurité Dependabot ».

Les développeurs Dart et JavaScript d’une instance avec le graphe des dépendances activé peuvent recevoir des alertes Dependabot pour les vulnérabilités connues dans les dépendances d’un projet.

• Pour Dart, le graphe des dépendances détecte les fichiers pubspec.lock et pubspec.yaml.
• Les développeurs JavaScript qui utilisent Node.js et npm peuvent recevoir des alertes pour les vulnérabilités connues dans les manifestes Yarn v2 et v3. Cela vient en complément de la prise en charge existante des manifestes v1. Le graphe des dépendances détecte les fichiers package.json et yarn.lock.

Pour plus d'informations, consultez les articles suivants.

• « À propos du graphe de dépendances »
• « Exploration des avis de sécurité dans la base de données GitHub Advisory »
• « À propos des alertes Dependabot »

Les développeurs Python qui utilisent des gestionnaires de package pris en charge sur une instance avec le graphe des dépendances activé peuvent recevoir des alertes Dependabot pour les dépendances dans les fichiers pyproject.toml qui suivent la norme PEP 621. Pour plus d’informations, consultez « À propos des mises à jour de version Dependabot ».

Les développeurs Python qui reçoivent des alertes Dependabot peuvent réduire le nombre de mises à jour de version lorsqu’un besoin de dépendance est déjà satisfait par une nouvelle version. Pour configurer ce comportement, utilisez la stratégie de gestion de versions increase-if-necessary. Pour plus d’informations, consultez « Options de configuration pour le fichier dependabot.yml ».

Les propriétaires d’entreprise peuvent récupérer les alertes Dependabot pour l’instance à l’aide de l’API REST. Ce point de terminaison est en version bêta et susceptible d’être modifié. Pour plus d’informations, consultez « Alertes Dependabot » dans la documentation de l’API REST.

Les propriétaires d’organisation peuvent récupérer les alertes Dependabot pour l’organisation à l’aide de l’API REST. Ce point de terminaison est en version bêta et susceptible d’être modifié. Pour plus d’informations, consultez « Alertes Dependabot ».

Les utilisateurs peuvent voir et agir programmatiquement sur les alertes Dependabot à l’aide de l’API REST. De nouveaux points de terminaison pour voir, lister et mettre à jour les alertes Dependabot sont disponibles dans la version bêta. Ces points de terminaison sont susceptibles d’être modifiés. Pour plus d’informations, consultez « Alertes Dependabot » dans la documentation de l’API REST.

Pour augmenter la visibilité de la posture de sécurité et améliorer l’analyse des risques, les utilisateurs peuvent accéder à des vues de couverture et de risque dans la vue d’ensemble de la sécurité. La vue de couverture montre l’activation des dépôts, tandis que la vue de risque expose les alertes des dépôts. Les propriétaires d’organisation, les responsables de la sécurité et les administrateurs de dépôt sur une instance avec une licence GitHub Advanced Security peuvent activer les fonctionnalités de sécurité à partir de la vue de couverture de la vue d’ensemble de la sécurité. Les vues remplacent la page « Vue d’ensemble » et sont en version bêta publique et susceptibles d’être modifiées. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Les contributeurs peuvent définir la stratégie de sécurité d’un dépôt en créant un fichier SECURITY.md. Pour augmenter la visibilité de la stratégie, GitHub Enterprise Server établit un lien avec la stratégie à partir de l’onglet Code du dépôt. Pour plus d’informations, consultez « Ajout d’une stratégie de sécurité à votre dépôt ».

L’API de révision des dépendances est en disponibilité générale et l’action GitHub associée permet désormais aux utilisateurs de référencer un fichier de configuration local ou externe. Pour plus d’informations, consultez la documentation suivante.

• « Révision des dépendances » dans la documentation de l’API REST
• « Configuration de la révision des dépendances »

L’API GraphQL permet d’accéder au graphe des dépendances d’un dépôt. Cette fonctionnalité étant en préversion, elle est susceptible d’être modifiée. Pour plus d’informations, consultez la documentation « Objets ».

Lors de la configuration du stockage pour GitHub Actions, les administrateurs de site peuvent éviter les risques associés à la saisie de secrets sensibles et de clés d’accès en utilisant OIDC pour se connecter à des fournisseurs de stockage d’objets. GitHub Actions sur GitHub Enterprise Server prend en charge OIDC pour les connexions à AWS, Azure et Google Cloud Platform. Cette fonctionnalité est en version bêta et est sujette à modifications. Pour plus d’informations, consultez « Activation de GitHub Actions pour GitHub Enterprise Server ».

Pour empêcher la journalisation non approuvée des données à partir des commandes de workflow set-state et set-output, les auteurs d’actions peuvent utiliser des fichiers d’environnement pour la gestion de l’état et de la sortie.

• Pour utiliser cette fonctionnalité, l’application de l’exécuteur doit avoir la version 2.297.0 ou ultérieure. Les versions 2.298.2 et ultérieures avertissent les utilisateurs qui se servent des commandes save-state ou set-output. Ces commandes seront entièrement désactivées dans une version ultérieure.
• Pour utiliser les fonctions saveState et setOutput mises à jour, les workflows utilisant le GitHub Actions Toolkit doivent appeler @actions/core version 1.10.0 ou ultérieure.

Pour plus d’informations, consultez « Commandes de workflow pour GitHub Actions ».

La possibilité de partager les actions et les workflows réutilisables de dépôts privés est en disponibilité générale. Les utilisateurs peuvent partager les workflows d’un dépôt privé avec d’autres dépôts privés appartenant au même compte d’utilisateur ou d’organisation, ou avec tous les dépôts privés de l’instance. Pour plus d’informations, consultez la documentation suivante.

• « Gestion des paramètres de GitHub Actions pour un dépôt »
• « Autorisations GitHub Actions » dans la documentation de l’API REST

Les utilisateurs peuvent améliorer la lisibilité des workflows et éviter d’avoir à stocker des données de configuration non sensibles sous forme de secrets chiffrés en définissant des variables de configuration, qui permettent une réutilisation entre les workflows d’un dépôt ou d’une organisation. Cette fonctionnalité est en version bêta et est sujette à modifications. Pour plus d’informations, consultez « Variables ».

Les utilisateurs peuvent nommer dynamiquement les exécutions de workflows. run-name accepte les expressions, et le nom dynamique apparaît dans la liste des exécutions de workflows. Pour plus d’informations, consultez « Syntaxe de workflow pour GitHub Actions ».

Les utilisateurs peuvent empêcher l’exécution d’un travail sur un exécuteur en dehors du groupe prévu en définissant les noms des groupes d’exécuteurs prévus pour un workflow dans la clé runs-on.

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

De plus, GitHub Enterprise Server n’autorise plus la création de groupes d’exécuteurs avec des noms identiques au niveau de l’organisation et de l’entreprise. Une bannière d’avertissement s’affiche pour tous les groupes d’exécuteurs d’une organisation qui partagent un nom avec un groupe d’exécuteurs de l’entreprise.

Les utilisateurs peuvent appliquer des pratiques CI/CD standard à tous les dépôts d’une organisation en définissant les workflows requis. Ces workflows sont déclenchés lors des vérifications d’état requises pour toutes les demandes de tirage qui ciblent la branche par défaut des dépôts, qui bloque la fusion jusqu’à ce que la vérification réussisse. Cette fonctionnalité est en version bêta et est sujette à modifications. Pour plus d’informations, consultez « Workflows requis ».

Pour pouvoir standardiser les configurations OIDC sur les workflows de déploiement cloud, les propriétaires d’organisation et les administrateurs de dépôt peuvent configurer le format de revendication subject dans les jetons OIDC en définissant un modèle personnalisé. Pour plus d’informations, consultez « À propos du durcissement de la sécurité avec OpenID Connect ».

Pour avoir plus de transparence et de contrôle sur l’utilisation du cache au sein des dépôts, les utilisateurs qui mettent en cache les dépendances et d’autres fichiers réutilisés avec actions/cache peuvent gérer les caches à partir de l’interface utilisateur web de l’instance. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».

Les utilisateurs peuvent définir les attentes relatives à la disponibilité en affichant un fuseau horaire local dans leur profil. Les personnes qui voient le profil ou la carte sensitive de l’utilisateur voient le fuseau horaire, ainsi que le nombre d’heures de retard ou d’avance sur l’heure locale de l’utilisateur. Pour plus d’informations, consultez « Personnalisation de votre profil ».

Pour améliorer la découvrabilité, GitHub Discussions présente les améliorations suivantes.

• Les propriétaires de dépôts peuvent épingler des discussions à une catégorie spécifique.
• Le titre et la description des catégories sont affichés dans la page de la catégorie.

Pour gérer la façon dont les membres de l’organisation dupliquent les dépôts, les propriétaires d’organisation peuvent définir une stratégie de duplication dédiée pour toute organisation. Cette stratégie doit être plus stricte qu’une stratégie de duplication définie pour l’entreprise. Pour plus d’informations, consultez « Gestion de la stratégie de duplication pour votre organisation ».

Les propriétaires d’organisation peuvent améliorer la sécurité de l’organisation en empêchant les collaborateurs externes de demander l’installation de GitHub et des applications OAuth. Pour plus d’informations, consultez « Limitation des demandes d’accès aux applications OAuth et GitHub ».

Pour éviter de fournir un accès administratif total à un dépôt lorsque cela n’est pas nécessaire, les administrateurs de dépôt peuvent créer un rôle personnalisé qui permet aux utilisateurs de contourner les protections de branches. Pour appliquer des protections de branches à tous les utilisateurs disposant d’un accès administratif ou d’autorisations de contournement, les administrateurs peuvent activer Ne pas autoriser le contournement des paramètres ci-dessus. Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation » et « À propos des branches protégées ».

Les administrateurs de dépôt peuvent garantir la sécurité et la stabilité des branches en exigeant l’approbation des demandes de tirage par une personne autre que le dernier pousseur, ou en verrouillant la branche. Pour plus d’informations, consultez « À propos des branches protégées ».

Dans les scénarios où une personne doit réviser le code d’un workflow GitHub Actions avant l’exécution du workflow, les administrateurs de dépôt peuvent exiger l’approbation d’un utilisateur disposant d’un accès en écriture au dépôt avant qu’une exécution du workflow ne puisse être déclenchée à partir d’une duplication privée. Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un référentiel ».

L’API GraphQL prend en charge la création et la suppression du lien entre une branche et un problème. Pour plus d’informations, consultez la documentation suivante.

• « Création d’une branche pour travailler sur un problème »
• « createLinkedBranch » et « deleteLinkedBranch » dans la documentation de l’API GraphQL « Mutations »
• « Objets » dans la documentation de l’API GraphQL

Les utilisateurs peuvent marquer une version spécifique dans un dépôt comme étant la dernière version via l’interface utilisateur web, l’API REST ou l’API GraphQL. Pour plus d’informations, consultez la documentation suivante.

• « Gestion des mises en production dans un dépôt »
• « Versions » dans la documentation de l’API REST
• « Objets » dans la documentation de l’API GraphQL

Les utilisateurs peuvent gagner du temps et changer de contexte moins souvent en recevant et en manipulant les mises à jour en temps réel de l’activité GitHub Enterprise Server directement dans Slack ou Microsoft Teams. Les intégrations de GitHub pour ces services sont désormais en disponibilité générale. Pour plus d’informations, consultez Extensions et intégrations GitHub.

Lorsqu’un administrateur de site exécute une commande à l’aide d’un accès SSH d’administration, la commande est désormais journalisée. Pour aider le support GitHub à résoudre les problèmes et à déboguer, les bundles de support incluent un journal contenant ces commandes.

Pour simplifier la découverte des événements dans les journaux d’audit d’entreprise, d’organisation ou d’utilisateur, la barre de recherche affiche désormais une liste de filtres disponibles.

Avant qu’un administrateur de site ne puisse migrer en dehors de GitHub Enterprise Server avec l’l’interface CLI de GitHub Enterprise Importer, l’API GraphQL startRepositoryMigration ou l’API REST Démarrer une migration d’organisation, il doit utiliser la console de gestion pour configurer un fournisseur de stockage d’objets blob pour le stockage des archives de migration. Les fournisseurs pris en charge incluent Amazon S3 et Stockage Blob Azure. Avant, le stockage d’objets blob n’était pas obligatoire et pouvait éventuellement être configuré avec gh gei. Ce changement ajoute la prise en charge des migrations pour lesquelles la source ou les métadonnées Git sont supérieures à 1 Go.

Pour aider les utilisateurs d’une instance avec une licence GitHub Advanced Security à mieux comprendre les secrets détectés et à prendre des mesures, les alertes d’analyse des secrets concernant les clés API tierces incluent désormais un lien vers la documentation du fournisseur. Pour plus d’informations, consultez « À propos de l’analyse des secrets ».

Les utilisateurs d’une instance avec une licence GitHub Advanced Security verront désormais les actions qu’ils ont effectuées suite à une alerte d’analyse des secrets directement dans la chronologie de l’alerte, y compris lorsqu’un contributeur a contourné la protection des poussées pour un secret.

Les instances avec une licence GitHub Advanced Security exécuteront régulièrement une analyse historique pour détecter les types de secrets récemment ajoutés sur les dépôts avec GitHub Advanced Security et l’analyse des secrets activés. Avant, les utilisateurs devaient procéder manuellement à une analyse historique.

Sur les instances avec une licence GitHub Advanced Security, pour garantir que les versions futures de GitHub Enterprise Server pourront toujours afficher un aperçu d’un secret détecté dans les API ou l’interface utilisateur web, les secrets détectés sont désormais stockés séparément du code source. Les secrets détectés sont stockés à l’aide d’un chiffrement symétrique. [Mise à jour : 15/02/2023]

Lorsque vous utilisez des registres privés pour les mises à jour Dependabot, GitHub Enterprise Server se comporte de manière plus sécurisée. Si un registre privé est configuré pour l’un des écosystèmes suivants, l’instance ne fait plus de demandes de package aux registres publics.

• Bundler
• Docker
• Gradle
• Maven
• npm
• NuGet
• Python
• Yarn

Pour plus d’informations, consultez « Options de configuration pour le fichier dependabot.yml ».

Les développeurs Elixir qui utilisent des dépôts Hex auto-hébergés peuvent configurer un registre privé pour les mises à jour de version Dependabot sur GitHub Enterprise Server. Pour plus d’informations, consultez « Options de configuration pour le fichier dependabot.yml ».

Les alertes Dependabot présentent les améliorations d’utilisabilité suivantes.

• La page d’une alerte s’actualise automatiquement après une tentative de Dependabot de créer une demande de tirage pour une mise à jour.
• Les alertes sont mappées de façon plus précise aux demandes de tirage des mises à jour Dependabot.
• Pour améliorer l’alerte pour la communauté, les utilisateurs peuvent suggérer des améliorations aux alertes directement dans la base de données GitHub Advisory Database.

Les utilisateurs peuvent plus facilement mentionner @dependabot . Lorsque vous mentionnez des utilisateurs, le compte d’utilisateur Dependabot apparaît désormais en suggestion d’autocomplétion.

Dans les dépôts avec des dépendances vulnérables, Dependabot n’affiche plus de bannière jaune. Pour avertir les contributeurs de dépendances vulnérables, l’onglet Sécurité affiche un compteur d’alerte.

Si un utilisateur duplique un dépôt avec une configuration Dependabot existante dans dependabot.yml, les mises à jour Dependabot sont désactivées dans la duplication par défaut. Pour activer les mises à jour dans la duplication, l’utilisateur doit consulter les paramètres de sécurité et d’analyse du code du dépôt. Pour plus d’informations, consultez « Configuration des mises à jour de version Dependabot ».

Les intégrateurs qui souhaitent recevoir un webhook pour les alertes Dependabot doivent utiliser le nouveau webhook dependabot_alert. Ce webhook remplace le webhook repository_vulnerability_alert. Pour plus d’informations, consultez « Événements et charges utiles de webhook ».

Pour améliorer la lisibilité des workflows GitHub Actions qui référencent d’autres actions par SHA de commit, les auteurs d’actions écrivent souvent un commentaire incluant la version sémantique correspondante sur la ligne qui appelle l’action. Pour gagner du temps, les demandes de tirage pour les mises à jour de version Dependabot mettent désormais automatiquement à jour la version sémantique dans ces commentaires.

Les développeurs JavaScript qui utilisent les mises à jour de sécurité Dependabot, Node.js et npm peuvent gagner du temps lors de la mise à jour des projets npm avec des dépendances transitives.

• Dependabot peut mettre à jour les dépendances parent et enfant ensemble. Avant, Dependabot ne mettait pas à jour les dépendances transitives lorsque le parent nécessitait une plage de versions spécifique incompatible, demandant des mises à niveau manuelles.
• Dependabot peut créer des demandes de tirage qui résolvent les alertes où une mise à jour vers une dépendance directe supprimerait la dépendance transitive vulnérable de l’arborescence.

Pour plus d’informations, consultez « À propos des mises à jour de sécurité Dependabot ».

Pour les personnes qui utilisent Dependabot pour les mises à jour de version dans l’écosystème Docker, Dependabot met à jour de manière proactive les étiquettes des images Docker dans les manifestes Kubernetes. Pour plus d’informations, consultez « Configuration des mises à jour de version Dependabot » et « Options de configuration pour le fichier dependabot.yml ».

Un certain nombre d’améliorations sont disponibles pour les utilisateurs qui contribuent aux avis de sécurité sur GitHub.com, notamment les changements suivants.

• Pour accélérer la révision, GitHub invite les utilisateurs à ajouter un motif pour le changement.
• Pour s’assurer que la contribution correspond à l’intention de l’utilisateur, GitHub ne réorganise pas les liens de référence dans le diff.

GitHub Actions présente les améliorations suivantes en matière de découvrabilité et d’accessibilité.

• L’expérience de navigation pour rechercher dans les workflows et les exécutions de workflow est améliorée.
• La structure ajoutée représente mieux la hiérarchie entre l’appelant et les workflows réutilisables appelés.
• L’expérience de navigation sur mobile est plus cohérente et prend en charge plusieurs tailles de fenêtre d’affichage.

Les workflows GitHub Actions ne se déclenchent plus à l’infini lors de l’utilisation de GITHUB_TOKEN avec les événements workflow_dispatch et repository_dispatch. Avant ce changement, les événements déclenchés par GITHUB_TOKEN ne créaient pas une nouvelle exécution de workflow. Pour plus d’informations, consultez « Déclenchement d’un workflow ».

Pour les exécutions planifiées de workflows GitHub Actions, les utilisateurs voient désormais des informations supplémentaires sur le dépôt, l’organisation et l’entreprise dans le contenu de github.event.

Les utilisateurs de GitHub Actions disposent d’un meilleur aperçu de la progression d’un travail lors de l’utilisation de règles de protection de l’environnement. Le webhook workflow_job prend en charge un nouvel état waiting chaque fois qu’un travail attend une règle de protection de l’environnement. De plus, lorsqu’un travail fait référence à une clé environment dans sa définition YAML, le contenu du webhook workflow_job inclut également une nouvelle propriété, deployment. deployment contient des métadonnées sur le déploiement créé par l’exécution de la vérification. Pour plus d’informations, consultez « Utilisation d’environnements pour le déploiement ».

Les propriétaires d’organisation peuvent trouver un contexte plus parlant dans les événements du journal d’audit.

• Les événements business.sso_response et org.sso_response apparaissent dans l’API REST et les charges utiles du streaming des journaux d’audit.
• Les événements repo.rename, project.rename et protected_branch.update_name incluent les noms actuels et passés de ceux qui ont été renommés dans le champ old_name.
• Les événements pour les alertes Dependabot contiennent les champs alert_number, ghsa_id, dismiss_reason et dismiss_comment, en plus d’un lien vers l’alerte et d’un horodatage précis.

Les utilisateurs peuvent voir une liste qui contient tous les abonnés d’une organisation à partir du profil de l’organisation.

La bannière affichée au-dessus d’un dépôt archivé dans l’interface utilisateur web inclut désormais la date d’archivage du dépôt.

Les onglets Conversations et Fichiers des demandes de tirage se chargent désormais plus rapidement en raison d’une coloration syntaxique différée.

Pour offrir une expérience plus cohérente entre l’interface utilisateur web et les stations de travail des utilisateurs, et pour accélérer le processus de vérification de la possibilité pour les utilisateurs de fusionner automatiquement une demande de tirage, GitHub Enterprise Server utilise désormais la stratégie merge-ort. Pour plus d’informations, consultez Stratégies de fusion dans la documentation Git.

Pour améliorer l’affichage du commentaire initial dans les demandes de tirage contenant un seul commit, GitHub Enterprise Server remet en forme automatiquement les messages de commit détaillés pour respecter les conventions Markdown de GitHub.

Avant la fusion Squash d’une demande de tirage, l’interface utilisateur web affiche l’adresse e-mail de l’auteur de la validation. Avant, l’auteur du commit s’affichait uniquement lors de la fusion avec un commit de fusion.

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

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 quand même démarrer correctement.

Dans certains cas, le processus de conversion peut se bloquer lors de la conversion d’un problème en discussion. Dans ce cas, un propriétaire d’entreprise peut essayer les étapes de résolution des problèmes suivantes pour résoudre le problème.

1. À la fin de l’URL de la discussion bloquée, notez le numéro de la discussion.
2. Dans l’interface utilisateur web, accédez au référentiel où la conversion est bloquée.
3. En haut à droite de l’interface utilisateur web, cliquez sur .
4. Sous « Collaboration », cliquez sur le Numéro des discussions.
5. Dans la liste, cliquez sur le nombre de l’étape 1.
6. Sous « Conversion », cliquez sur Empiler le travail de conversion.
7. Patientez quelques minutes, puis vérifiez l’état du problème.

Si la conversion ne s’effectue toujours pas, contactez le Support GitHub Enterprise pour obtenir de l’aide.

Si l’administrateur de site racine est verrouillé hors de la console de gestion après des échecs de tentative de connexion, le compte ne se déverrouille pas automatiquement après le temps de verrouillage défini. Une personne disposant d’un accès SSH administratif à l’instance doit déverrouiller le compte à l’aide de l’interpréteur de commandes d’administration. Pour plus d’informations, consultez « Résolution des problèmes d’accès à la console de gestion ». [Mise à jour : 23/02/2023]

Pendant une mise à niveau vers GitHub Enterprise Server 3.8.0 sur un cluster, après la mise à niveau des nœuds autres que le nœud MySQL principal et avant la mise à niveau du nœud MySQL principal, l’erreur suivante peut apparaître plusieurs fois après l’exécution de ghe-cluster-config-apply.

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

GitHub recommande d’attendre la mise à niveau de votre cluster jusqu’à ce que ce problème soit résolu. Plus d’informations seront disponibles dans les notes de publication lors d’une prochaine mise à jour de GitHub Enterprise Server.

Après la mise à niveau vers GitHub Enterprise Server 3.8.0, les commandes exécutées via le protocole SSH sur tout nœud de l’instance ne sont pas consignées dans /var/log/ssh-console-audit.log. Pour résoudre ce problème, connectez-vous au nœud affecté via le protocole SSH et exécutez la commande suivante.

source /etc/bash.bashrc

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]

L’utilisation de l’API de recherche peut entraîner l’échec des demandes ultérieures adressées à d’autres interfaces. Quand ce problème se produit, les utilisateurs de l’API ou de l’interface utilisateur web affectés reçoivent des réponses HTTP 5xx et cette exception NoMethodError est journalisée :

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