Enterprise Server 3.5 release notes

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

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

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

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

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

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

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

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

If a repository contained a CODEOWNERS file, pull requests in the repository intermittently failed to display the files validity or updated code owner information, requiring the user to reload the page.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sanitize additional secrets in support bundles and the configuration log.

Dependencies for the CodeQL action have been updated to the latest security versions.

Packages have been updated to the latest security versions.

The metrics Active workers and Queued requests for github (renamed from metadata), gitauth, and unicorn container services werent correctly read from collectd and displayed in the Management Console.

Dependabot Alert emails would be sent to disabled repositories.

Repositories locked for migration would allow files to be edited in the web UI.

When viewing a pull requests diff for a large file with many lines between changes, it was not possible to expand the view to display all of the changes.

The git-janitorcommand was unable to fix outdated multi-pack-index.lock files, resulting in the repository failing maintenance.

The ghe-support-bundle and ghe-cluster-support-bundle commands were updated to include the -p/--period flag to generate a time constrained support bundle. The duration can be specified in days and hours, for example: -p '2 hours', -p '1 day', -p '2 days 5 hours'.

The performance of configuration runs started with ghe-config-apply has been improved.

When upgrading an instance with a new root partition, running the ghe-upgrade command with the -t/--target option ensures the preflight check for the minimum disk storage size is executed against the target partition.

When exporting account data, backing up a repository, or performing a migration, the link to a repository archive now expires after 1 hour. Previously the archive link expired after 5 minutes.

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

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

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

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

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.

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.

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

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.

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.

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

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

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

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

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

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

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

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

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

Lors de l’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.

Lorsqu’un propriétaire d’entreprise empruntait l’identité d’un utilisateur et essayait d’installer une application GitHub, le bouton permettant de confirmer l’installation était désactivé, et aucun clic n’était possible.

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.

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

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

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

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

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

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

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

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

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

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

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

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

Résolution d’un bogue à cause duquel le point de terminaison de création d’un état de protection d’étiquette pour un dépôt renvoyait une erreur 500.

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

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

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

Dans certains cas, sur une instance avec une licence GitHub Advanced Security, les alertes d’analyse des secrets n’incluaient pas de type de fournisseur et indiquaient plutôt que le type de fournisseur était « inconnu ».

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

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

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

MOYENNE : l’utilisation d’un caractère de remplacement Unicode de droite à gauche dans la liste des fichiers accessibles pour une application GitHub pouvait masquer les fichiers supplémentaires auxquels l’application pouvait accéder.

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

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

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

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

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

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

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

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

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

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

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

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

Une fois qu’un utilisateur supprimait ou restaurait des packages de l’interface web, le nombre de packages pouvait s’afficher incorrectement.

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

Après la mise à niveau vers GitHub Enterprise Server 3.5, les versions semblent manquer dans les dépôts. Cela se produisait lorsque les migrations d’index Elasticsearch requises n’étaient pas été effectuées avec succès. L’interface utilisateur des mises en production indique maintenant si elle attend la fin des migrations d’index Elasticsearch, et fournit des liens vers la documentation sur l’observation de l’état et la fin immédiate de la migration.

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

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

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

Sur les instances utilisant GitHub Advanced Security, l’analyse des secrets révoque automatiquement les jetons d’accès personnel ajoutés aux dépôts publics.

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

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

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

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

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

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

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

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

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

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

Lorsqu’un utilisateur dupliquait un référentiel vers une organisation, une longue liste d’organisations ne s’affichait pas correctement.

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

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

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

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

CRITIQUE : Le conteneur Elasticsearch de GitHub Enterprise Server utilise une version d’OpenJDK 8, qui est vulnérable à un problème de troncature d’entier durant le traitement de feuilles de style XSLT malveillantes. La vulnérabilité fait l’objet d’un suivi dans la CVE-2022-34169.

ÉLEVÉ : Les applications installées sur des comptes d’utilisateur se voyaient automatiquement octroyer l’autorisation d’accéder à une organisation avec des jetons d’accès délimités, une fois le compte d’utilisateur transformé en compte d’organisation. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty.

Dans certains cas, les instances GitHub Enterprise Server sur AWS qui utilisaient le type d’instance r4.4xlarge ne démarraient pas.

Dans certains cas, les éléments de l’interface utilisateur sous l’onglet Fichiers modifiés d’une demande de tirage pouvaient se chevaucher.

Lorsqu’un seuil de dormance personnalisé était défini pour l’instance, la suspension de tous les utilisateurs dormants ne respectait pas le seuil de manière fiable. Pour plus d’informations sur la dormance, consultez « Gestion des utilisateurs dormants ».

Lors du calcul des validateurs pour GitHub Advanced Security, il n’était pas possible de spécifier des référentiels individuels. Pour plus d’informations, consultez « Tableau de bord d’administration de site ».

Dans certains cas, le processus de post-mise à niveau es:upgrade d’Elasticsearch pouvait planter avant la fin.

Le script de migration vers les référentiels internes ne parvenait pas à convertir la visibilité des référentiels publics en référentiels internes ou privés. Pour plus d’informations sur la migration, consultez « Migration vers des dépôts internes ».

La détection des fichiers de workflow GitHub Actions pour le graphe des dépendances n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3, mais l’est désormais dans la version 3.5.4. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

La possibilité de rouvrir des alertes Dependabot rejetées n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3, mais l’est désormais dans la version 3.5.4. Pour plus d’informations, consultez « Affichage et mise à jour des alertes Dependabot ».

La possibilité de toujours suggérer des mises à jour de la branche de base vers le HEAD d’une demande de tirage n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3, mais l’est désormais dans la version 3.5.4. Pour plus d’informations, consultez « Gestion des suggestions de mise à jour des branches de demande de tirage ».

Le thème clair à fort contraste n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3, mais l’est désormais dans la version 3.5.4. Pour plus d’informations, consultez « Gestion de vos paramètres de thème ».

Les événements pre_receive_hook.rejected_push n’étaient pas affichés dans le journal d’audit de l’entreprise.

MOYEN : Empêche une attaque au cours de laquelle une falsification de requête côté serveur (SSRF) peut forcer le pont Subversion (SVN) à exécuter du code à distance en injectant des données arbitraires dans Memcached.

MOYEN : Empêche un attaquant d’exécuter du code JavaScript en exploitant une vulnérabilité XSS (scripting intersite) dans les éléments d’IU de liste déroulante au sein de l’interface web de GitHub Enterprise Server.

Met à jour Grafana vers la version 7.5.16, qui corrige diverses failles de sécurité, notamment les CVE-2020-13379 et CVE-2022-21702.

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

MOYEN : Une vulnérabilité XSS stockée a été identifiée dans GitHub Enterprise Server. Elle permet l’injection d’attributs arbitraires. Cette injection a été bloquée par la stratégie de sécurité du contenu (CSP) de Github. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty, et s’est vu affecter l’identifiant CVE-2022-23733. [Mise à jour : 31/07/2022]

MOYEN : Une vulnérabilité impliquant la désérialisation de données non approuvées a été identifiée dans GitHub Enterprise Server, ce qui peut entraîner l’exécution de code à distance sur le pont Subversion (SVN). Pour exploiter cette vulnérabilité, un attaquant doit obtenir l’accès via une falsification de requête côté serveur (SSRF), ce qui lui permet de contrôler les données en cours de désérialisation. Cette vulnérabilité a été signalée via le programme GitHub Bug Bounty et s’est vu affecter le numéro CVE-2022-23734.

Dans certains cas, le démon collectd pouvait consommer une quantité excessive de mémoire.

Dans certains cas, les sauvegardes des fichiers journaux en rotation pouvaient s’accumuler et consommer un excès de stockage.

Après une mise à niveau vers une nouvelle mise en production de fonctionnalité et une exécution de configuration ultérieure, Elasticsearch pouvait enregistrer des exceptions excessives lors de la reconstruction des indices.

Dans certains cas, lorsqu’une branche protégée nécessitait plus d’une révision approuvée, une demande de retrait pouvait être fusionnée avec moins que le nombre requis de révisions approuvées.

GitHub Enterprise Importer ne migrait pas correctement les paramètres des projets dans les dépôts.

Sur les instances utilisant l’authentification LDAP, l’invite d’authentification pour le mode sudo plaçait incorrectement le curseur dans le champ du mot de passe par défaut lorsque les champs de texte pour un nom d’utilisateur et un mot de passe étaient visibles.

Le tableau de bord de l’administrateur de site incluait par erreur une option permettant d’exporter un rapport répertoriant les utilisateurs dormants.

Le point de terminaison « Facturation » de l’API de facturation renvoie désormais les en-têtes Link pour fournir des informations sur la pagination.

Le point de terminaison « Facturation » de l’API de facturation renvoie désormais le nombre correct de validateurs totaux.

Dans la barre latérale des paramètres d’une organisation, l’élément de navigation Archive ne contenait aucun enfant.

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

L’utilitaire de ligne de commande ghe-set-password démarre automatiquement les services requis lorsque l’instance est démarrée en mode récupération.

Les métriques des processus d’arrière-plan aqueduct sont collectées pour le transfert Collectd, puis affichées dans la console de gestion.

L’emplacement du journal d’exécution de la migration et de la configuration de la base de données, /data/user/common/ghe-config.log, est maintenant affiché sur la page qui détaille une migration en cours.

MOYENNE : Empêche une attaque où un paramètre de chaîne de requête org peut être spécifié pour une URL GitHub Enterprise Server, qui donne ensuite accès aux commiteurs actifs d’une autre organisation.

MOYENNE : S’assure que github.company.com et github-company.com ne sont pas évalués par les services internes comme des noms d’hôte identiques, empêchant ainsi une attaque potentielle de type SSRF (Server Side Request Forgery).

FAIBLE : Un attaquant pouvait accéder à la console de gestion par une attaque de traversée de chemin via HTTP, même si les règles du pare-feu externe bloquaient l’accès HTTP.

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

Les fichiers à l’intérieur d’une archive d’artefact ne pouvaient pas être ouverts après décompression en raison d’autorisations restrictives.

Dans certains cas, les packages poussés vers le registre de conteneurs n’étaient pas visibles dans l’interface utilisateur web de GitHub Enterprise Server.

La console de gestion pouvait apparaître bloquée sur l’écran Démarrage après la mise à niveau d’une instance sous-provisionnée vers GitHub Enterprise Server 3.5.

Les expirations de Redis n’interrompent plus les migrations de bases de données lors de l’exécution de ghe-config-apply.

Les processeurs de travaux d’arrière-plan restaient bloqués dans un état d’arrêt partiel, ce qui avait pour conséquence de bloquer certains types de travaux d’arrière-plan (comme l’analyse du code).

Dans certains cas, les administrateurs de site n’étaient pas automatiquement ajoutés en tant que propriétaires d’entreprise.

Les workflows d’actions appelant d’autres workflows réutilisables n’ont pas pu s’exécuter selon une planification.

La résolution des actions avec GitHub Connect a échoué très vite après avoir changé la visibilité du dépôt de publique à interne.

Amélioration des performances des mises à jour Dependabot lors de la première activation.

Augmentation du nombre maximal de connexions simultanées pour les exécuteurs d’actions afin de prendre en charge la cible de performances GHES.

Les délais de génération et de synchronisation de GitHub Pages sont désormais configurables dans la console de gestion.

Ajout d’une variable d’environnement pour configurer les délais d’expiration de Redis.

La création ou la mise à jour d’exécutions de vérifications ou de suites de vérifications pouvait retourner 500 Internal Server Error, si la valeur de certains champs, par exemple le nom, était trop longue.

Amélioration des performances sous l’onglet « Fichiers modifiés » des demandes de tirage lorsque la différence inclut de nombreuses modifications.

La stratégie d’utilisation de cache de dépôt Actions n’accepte plus de valeur maximale inférieure à 1 pour max_repo_cache_size_limit_in_gb.

Lors du déploiement de nœuds de serveur de cache, il est maintenant obligatoire de décrire la topologie du centre de données (à l’aide de l’argument --datacenter) pour chaque nœud du système. Cette exigence permet d’éviter les situations où le fait de laisser l’appartenance à un centre de données définie sur « par défaut » entraîne une répartition inappropriée des charges de travail entre plusieurs centres de données.

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

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

Un script interne permettant de valider les noms d’hôtes dans le fichier de configuration GitHub Enterprise Server renvoyait une erreur si la chaîne de noms d’hôtes commençait par « . » (caractère point).

Dans les configurations HA où le nom d’hôte du nœud principal comportait plus de 60 caractères, la configuration de MySQL échouait.

Lorsque GitHub Actions était activé mais que TLS était désactivé sur GitHub Enterprise Server 3.4.1 et versions ultérieures, l’application d’une mise à jour de la configuration échouait.

L’argument --gateway a été ajouté à la commande ghe-setup-network, pour permettre de passer l’adresse de la passerelle lors de la configuration des paramètres réseau en utilisant la ligne de commande.

Les points de terminaison de l’API de facturation GitHub Advanced Security n’étaient pas activés et accessibles.

Les pièces jointes d’images qui ont été supprimées retournent une erreur 500 Internal Server Error au lieu de 404 Not Found.

Dans les environnements configurés avec un serveur de cache de référentiel, la commande ghe-repl-status montrait incorrectement les gists comme étant sous-répliqués.

Les points de terminaison « Obtenir une validation » et « Comparer deux validations » de l’API de validation renvoyaient une erreur 500 si le chemin d’accès d’un fichier dans le diff contenait un caractère Unicode encodé et échappé.

Le calcul du « nombre maximum de validateurs sur l’ensemble de l’instance » indiqué dans le tableau de bord d’administration du site était incorrect.

Une entrée de base de données incorrecte pour les réplicas du référentiel provoquait une altération de la base de données lors de l’exécution d’une restauration à l’aide de GitHub Enterprise Server Backup Utilities.

Une GitHub App ne peut pas s’abonner à l’événement de webhook secret_scanning_alert_location sur une installation.

La chronologie de l’activité des alertes d’analyse des secrets ne s’affichait pas.

Les dépôts supprimés n’étaient pas été vidés après 90 jours.

Optimisation de l’inclusion des métriques lors de la génération d’un pack de support de cluster.

Dans les configurations HA (haute disponibilité) où Elasticsearch signalait un état jaune valide, les changements introduits par un correctif précédent bloquaient la commande ghe-repl-stop, et ne permettaient pas d’arrêter la réplication. L’utilisation de ghe-repo-stop --force va maintenant forcer Elasticsearch à s’arrêter lorsque le service est dans un état normal ou jaune valide.

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

Vous pouvez configurer une liste verte d’adresses IP pouvant accéder aux services d’application sur votre instance GitHub Enterprise Server tandis que le mode maintenance est activé. Les administrateurs qui visitent l’interface web de l’instance à partir d’une adresse IP autorisée peuvent valider la fonctionnalité de l’instance post-maintenance et avant la désactivation du mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

Grâce aux rôles de référentiel personnalisés, les organisations disposent désormais d’un contrôle granulaire plus élevé sur les autorisations d’accès du référentiel octroyables aux utilisateurs. Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Un rôle de référentiel personnalisé est créé par le propriétaire d’une organisation et est disponible sur tous les référentiels de cette organisation. Chaque rôle peut se voir octroyer un nom et une description personnalisés. Vous pouvez le configurer à partir d’un ensemble de plus de 40 autorisations détaillées. Une fois la création terminée, les administrateurs de référentiel peuvent attribuer un rôle personnalisé à n’importe que utilisateur, équipe ou collaborateur extérieur à leur référentiel.

Des rôles de dépôt personnalisés peuvent être créés, affichés, modifiés et supprimés via le nouvel onglet Rôles de dépôt dans les paramètres de l’organisation. Vous pouvez créer un maximum de 3 rôles personnalisés dans une organisation.

Les rôles de référentiel sont également complètement pris en charge dans les API REST GitHub Enterprise Server. Les API d’organisations peuvent être utilisés pour répertorier tous les rôles de référentiel personnalisés de l’organisation et les API existantes pour octroyer un accès aux référentiels aux individus et aux équipes ont été étendus pour la prise en charge des rôles de référentiel personnalisés. Pour plus d’informations, consultez « Organisations » dans la documentation de l’API REST.

Le Registre de conteneurs GitHub (GHCR) est à présent disponible dans GitHub Enterprise Server 3.5 en tant que version bêta publique et offre aux développeurs la capacité de publier, télécharger et gérer des conteneurs. Le support de conteneurs des Packages GitHub implémente les normes OCI pour les images Docker d’hébergement. Pour plus d’informations, consultez « Registre de conteneurs GitHub ».

La version Dependabot et les correctifs de sécurité sont désormais généralement disponibles dans GitHub Enterprise Server 3.5. Tous les écosystèmes et fonctionnalités populaires utilisés sur les référentiels GitHub.com peuvent désormais être configurés sur votre instance GitHub Enterprise Server. Dependabot sur GitHub Enterprise Server nécessite GitHub Actions et un pool d’exécuteurs Dependabot auto-hébergés, GitHub Connect activé et Dependabot activé par un administrateur. Pour plus d’informations, consultez « Configuration des mises à jour de Dependabot ».

Vous pouvez à présent analyser le fonctionnement de votre équipe, comprendre la valeur obtenue par GitHub Enterprise Server et nous aider à améliorer nos produits en évaluant vos données d’utilisation d’instance et en partageant ces données agrégées avec GitHub. Vous pouvez utiliser vos propres outils pour analyser votre utilisation dans la durée en téléchargeant vos données dans un fichier CSV ou JSON ou en y accédant à l’aide de l’API REST. Pour voir la liste des métriques agrégées collectées, consultez « À propos des statistiques de serveur ». Les données de statistiques du serveur n’incluent aucune donnée personnelle ni aucun contenu GitHub comme du code, des problèmes, des commentaires ou du contenu de demandes de tirage (pull request). Pour mieux comprendre comment nous stockons et sécurisons les données de statistiques de serveur, consultez « Sécurité GitHub ». Pour plus d’informations sur les statistiques de serveur, consultez « Analyse du fonctionnement de votre équipe avec les statistiques de serveur ». Cette fonctionnalité est disponible dans une version bêta publique.

Les administrateurs du site peuvent à présent activer et configurer une limite de débit de GitHub Actions. Par défaut, la limite de débit est désactivée. Lorsque des tâches de workflow ne peuvent pas être immédiatement attribuées à un exécuteur disponible, elles attendent dans une file d’attente que l’exécuteur soit disponible. Toutefois, si GitHub Actions connaît une charge élevée soutenue, la file d'attente peut sauvegarder plus rapidement qu’elle peut vider et le niveau de performance de l’instance GitHub Enterprise Server peut être dégradé. Pour éviter cela, un administrateur peut configurer une limite de débit. Une fois la limite de débit dépassée, les exécutions supplémentaires du workflow échouent immédiatement plutôt que d’être placées en file d’attente. Une fois le débit stabilisé en-dessous du seuil, de nouvelles exécutions peuvent être remises en file d’attente. Pour plus d’informations, consultez « Configuration des limites de débit ».

GitHub Actions sur GitHub Enterprise Server prend désormais en charge OIDC pour des déploiements sécurisés sur des fournisseurs de cloud. Il utilise des jetons à courte durée de vie qui alternent automatiquement lors de chaque déploiement. OIDC active les fonctionnalités suivantes.

• Authentification transparente entre les fournisseurs de cloud et GitHub Enterprise Server sans avoir besoin de stocker des secrets cloud de longue durée sur votre instance
• Les administrateurs de cloud peuvent compter sur des mécanismes de sécurité d’un fournisseur de cloud particulier pour garantir que les workflows GitHub Actions disposent d’un accès minimal aux ressources cloud. Il n’existe pas de duplication de la gestion des secrets entre GitHub Enterprise Server et le cloud.

Pour plus d’informations, consultez « Renforcement de la sécurité de vos déploiements ».

Le support de GitHub Actions dans des référentiels internes est à présent généralement disponible pour des organisations sur votre instance GitHub Enterprise Server. Vous pouvez rétribuer l’automatisation en partageant des actions dans des référentiels internes. Vous pouvez gérer les paramètres d’un référentiel ou utiliser l’API REST pour autoriser l’accès aux workflows dans d’autres référentiels au sein de l’organisation ou dans toutes les organisations de l’instance. Pour plus d’informations, consultez « Partage d’actions et de workflows au sein de votre entreprise », « Gestion des paramètres de GitHub Actions pour un dépôt » et « Autorisations Actions » dans la documentation de l’API REST.

Vous pouvez désormais utiliser la mise en cache des dépendances pour accélérer vos workflows GitHub Actions. Pour mettre en cache les dépendances d’un travail, vous pouvez inclure l’action actions/cache pour créer un cache avec une clé unique. Vous pouvez partager des caches sur tous les workflows dans le même référentiel. Ces workflows peuvent alors restaurer le cache et s’exécuter plus rapidement.

Actions que les utilisateurs peuvent également utiliser pour les API de cache pour :

• Définir la stratégie d’entreprise pour la plage de tailles de cache autorisée par dépôt.
• Interroger l’utilisation du cache dans chaque dépôt et surveiller si la taille totale de tous les caches atteint la limite supérieure.
• Augmenter la taille maximale du cache pour un dépôt dans les limites autorisées de l’entreprise et en fonction des besoins de cache du dépôt.
• Surveiller l’utilisation agrégée du cache au niveau de l’organisation ou de l’entreprise.

Le stockage de blob externe configuré au sein de votre compte d’entreprise sera désormais partagé entre des artefacts, des journaux et également des caches de workflows. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».

Vous pouvez désormais configurer GitHub Enterprise Server pour signer automatiquement des validations effectuées dans l’interface web, notamment à partir de la modification d’un fichier ou de la fusion d’une demande de tirage (pull request). Les validations signées augmentent la confiance quant à la provenance de sources approuvées des modifications. Cette fonctionnalité permet au paramètre de protection de branche Exiger des commits signés d’empêcher les commits non signés d’entrer dans un dépôt, tout en autorisant l’entrée des commits signés, même ceux effectués dans l’interface web. Pour plus d’informations, consultez « Configuration de la signature de commit web ».

Pour les clients qui synchronisent l’utilisation de licences entre GitHub Enterprise Server et GitHub Enterprise Cloud automatiquement avec GitHub Connect, il est désormais possible de synchroniser l’utilisation des licences indépendamment de la synchronisation automatique hebdomadaire. Cette fonctionnalité indique également l’état du travail de synchronisation. Pour plus d’informations, consultez « Synchronisation de l’utilisation des licences entre GitHub Enterprise Server et GitHub Enterprise Cloud ».

Les workflows réutilisables sont désormais généralement disponibles. Les workflows réutilisables vous aident à réduire la duplication en vous permettant de réutiliser un workflow complet comme s’il s’agissait d’une action. Avec la mise en production de disponibilité générale, de nombreuses améliorations sont désormais disponibles pour GitHub Enterprise Server. Pour plus d’informations, consultez « Réutilisation de workflows ».

• Vous pouvez utiliser des sorties pour transmettre des données de workflows réutilisables à d’autres travaux dans le workflow appelant.
• Vous pouvez transmettre des secrets d’environnement à des workflows réutilisables.
• Le journal d’audit inclut des informations sur les workflows réutilisables utilisés.
• Les workflows réutilisables du même dépôt, comme le dépôt appelant, peuvent être référencés avec juste le chemin et le nom de fichier (PATH/FILENAME). Le workflow appelé est issu de la même validation que le workflow appelant.

Vous disposez maintenant d’un meilleur contrôle lorsque vos exécuteurs auto-hébergés effectuent des mises à jour de logiciel. Si vous spécifiez l’indicateur --disableupdate à l’exécuteur, celui-ci ne tente pas d’effectuer une mise à jour logicielle automatique si une version plus récente de l’exécuteur est disponible. Ceci vous permet de mettre à jour l’exécuteur auto-hébergé de votre planification et est particulièrement utile lorsque votre exécuteur auto-hébergé est un conteneur.

Pour la compatibilité avec le service GitHub Actions, vous devrez mettre à jour manuellement votre exécuteur dans les 30 jours suivant la disponibilité de la version de l’exécuteur. Pour obtenir des instructions sur la façon d’installer la dernière version de l’exécuteur, consultez les instructions d’installation de la dernière version dans le dépôt de l’exécuteur.

Les propriétaires d’organisations peuvent désormais augmenter la sécurité des workflows CI/CD sur des exécuteurs auto-hébergés en choisissant les workflows pouvant avoir accès à un groupe d’exécuteurs. Précédemment, tous les workflows d’un référentiel, comme par exemple un étiqueteur de problèmes, pouvaient avoir accès aux exécuteurs auto-hébergés disponibles pour une organisation. Pour plus d’informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes » et le blog GitHub.

Vous pouvez à présent contrôler l’approbation des demandes de tirage (pull request) par GitHub Actions. Cette fonctionnalité empêche un utilisateur utilisant GitHub Actions de répondre aux exigences de protection de branche « Approbations obligatoires » et de fusionner une modification non révisée par un autre utilisateur. Pour éviter l’arrêt de workflows existants, Autoriser les révisions de GitHub Actions à compter pour une approbation requise est activé par défaut. Les propriétaires des organisations peuvent désactiver la fonctionnalité dans les paramètres GitHub Actions de l’organisation. Pour plus d’informations, consultez « Désactivation ou limitation de GitHub Actions pour votre organisation ».

Vous pouvez à présent réexécuter les travaux non réussis uniquement ou un travail individuel dans une exécution de workflow GitHub Actions. Pour plus d’informations, consultez « Réexécution de workflows et de travaux ».

Le graphe des dépendances détecte à présent des fichiers YAML pour des workflows GitHub Actions. GitHub Enterprise Server affiche les fichiers de workflow dans la section Graphe des dépendances de l’onglet Insights. Les référentiels qui publient des actions seront également en mesure de voir le nombre de référentiels qui dépendent de cette action à partir du contrôle « Utiliser par » sur la page d’accueil de référentiel. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

• Remarque : Cette fonctionnalité n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3. La fonctionnalité est disponible dans la version 3.5.4 et ultérieure. [Mise à jour : 16/08/2022]

Les clients GitHub Advanced Security peuvent à présent afficher une vue d’ensemble des alertes de sécurité au niveau de l’entreprise. Le nouvel onglet Sécurité au niveau de l’entreprise offre une vue orientée dépôt des risques de sécurité de l’application, ainsi qu’une vue orientée alerte de toutes les alertes d’analyse des secrets. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

La vue d’ensemble des alertes de sécurité au niveau de l’organisation est maintenant en disponibilité générale. Les clients GitHub Advanced Security utilisent la vue d’ensemble sécurité pour un affichage centré sur le référentiel des risques de sécurité des applications ou un affichage centré sur les alertes de toutes les alertes d’analyse du code, Dependabot et d’analyse des secrets pour tous les référentiels dans une organisation. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

L’analyse du code détecte à présent un nombre plus élevé de CWE et l’analyse du code CodeQL prend complètement en charge les fonctionnalités de langage standard dans les mises en production du langage suivantes.

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

Pour plus d’informations, consultez le blog API GitHub Packages.

Les clients GitHub Advanced Security peuvent désormais voir les alertes d’analyse du code sous l’onglet Sécurité d’une organisation. Cette vue est disponible pour les propriétaires d’organisation et les membres des équipes disposant du rôle Gestionnaire de sécurité. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Les utilisateurs peuvent à présent récupérer des alertes d’analyse de code pour une organisation de votre instance GitHub Enterprise Server via l’API REST. Ce nouveau point de terminaison d’API complète le point de terminaison existant pour les dépôts. Pour plus d’informations, consultez Analyse du code dans la documentation de l’API REST.

GitHub Enterprise Server peut à présent bloquer tous les envois (push) lorsqu’un jeton est détecté avec un haut niveau de confiance. Les développeurs peuvent contourner le bloc en fournissant des détails sur la raison de la validation des besoins de secret via une interface utilisateur web. Pour plus d’informations, consultez « Protection des poussées avec l’analyse des secrets ».

Les clients GitHub Advanced Security peuvent tester des modèles d’analyse des secrets personnalisés au niveau d’une organisation ou référentiel. Les tests permettent aux personnes avec un accès propriétaire ou administrateur pour évaluer et explorer leurs modèles avant de les publier et de générer des alertes. Vous pouvez composer un modèle, puis utiliser Enregistrer et tester pour récupérer les résultats. Les analyses ne prennent généralement que quelques secondes, mais GitHub Enterprise Server informera les propriétaires de l’organisation ou les administrateurs de référentiels par e-mail une fois les résultats des tests prêts. Pour plus d’informations, consultez « À propos de l’analyse de secrets » et « Définition de modèles personnalisés pour l’analyse des secrets ».

Le journal d'audit contient à présent des événements associés aux modèles personnalisés de l’analyse des secrets. Ces données aident les clients GitHub Advanced Security à comprendre les actions effectuées sur leurs modèles personnalisés de dépôt, d’organisation ou d’entreprise pour les audits de sécurité et de conformité. Pour plus d’informations, consultez « Examen du journal d’audit pour votre organisation » ou « Examen des journaux d’audit pour votre entreprise ».

Vous pouvez à présent deux nouvelles autorisations pour l’analyse des secrets lors de la gestion des rôles de référentiel personnalisés.

• Afficher des résultats d’analyse des secrets
• Ignorer ou rouvrir des résultats d’analyse des secrets

Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Les clients GitHub Advanced Security peuvent maintenant activer une analyse des secrets pour des référentiels archivés via l’interface utilisateur et l’API. Pour plus d’informations, consultez « À propos de l’analyse des secrets », « À propos des dépôts archivés » et « Dépôts » dans la documentation de l’API REST.

Les clients GitHub Advanced Security qui utilisent l’analyse des secrets peuvent désormais choisir de recevoir un webhook à chaque fois qu’un secret est détecté dans un nouvel emplacement. L’événement webhook secret_scanning_alert_location inclut des détails de localisation, comme le SHA de commit, et l’alerte associée pour la détection. Un emplacement est créé pour chaque nouveau chemin de fichier contenant le secret détecté. Pour plus d’informations, consultez « Événements et charges utiles de webhook ».

Les clients GitHub Advanced Security peuvent désormais voir les alertes Dependabot sous l’onglet Sécurité d’une organisation. Cette vue est disponible pour les propriétaires d’organisation et les membres des équipes disposant du rôle Gestionnaire de sécurité. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Vous pouvez à présent configurer deux nouvelles autorisations pour des alertes Dependabot lors de la gestion de rôles de référentiel personnalisés.

• Visualiser les alertes Dependabot
• Ignorer ou rouvrir des alertes Dependabot

Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Vous pouvez désormais réouvrir des alertes Dependabot ignorées via la page Interface utilisateur pour une alerte fermée. Ceci n’affecte pas les demandes de tirage (pull request) ni les API GraphQL. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

• Remarque : Cette fonctionnalité n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3. La fonctionnalité est disponible dans la version 3.5.4 et ultérieure. [Mise à jour : 16/08/2022]

Les utilisateurs des mises à jour de versions Dependabot peuvent à présent mettre à jour des dépendances de façon proactive pour des projets Flutter ou Dart qui utilisent le gestionnaire de packages Pub.

Pour tester les mises à jour de version sur votre propre dépôt Dart ou Flutter, ajoutez le fichier de configuration suivant dans .github/dependabot.yaml. Notez les indicateurs package-ecosystem: "pub" et enable-beta-ecosystems: true.

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"

Le nouvel objet GraphQL DependabotUpdate vous permet d’afficher des informations sur ce qui se passe avec les correctifs de sécurité de votre dépôt. Lorsque GitHub Enterprise Server détecte une dépendance vulnérable dans votre référentiel, Dependabot tente d’ouvrir une demande de tirage (pull request) pour mettre à jour cette dépendance vers une version non vulnérable. Vous pouvez désormais afficher la demande de tirage (pull request) qui corrige la vulnérabilité. Dans certains cas, Dependabot échoue a ouvrir une demande de tirage (pull request). Avant, le message d’erreur généré par Dependabot était uniquement visible dans la section « Alertes Dependabot » de l’onglet Sécurité. Maintenant, si Dependabot rencontre une erreur au moment d’essayer d’ouvrir une demande de tirage pour une alerte de sécurité, vous pouvez déterminer le motif à l’aide de l’API GraphQL. Pour plus d’informations, consultez la documentation « Objets ».

Vous pouvez désormais afficher des alertes corrigées à partir de Dependabot avec l’API GraphQL. Vous pouvez également accéder et filtrer par état, ainsi que par identificateur numérique unique et vous pouvez filtrer par état sur l’objet de l’alerte de vulnérabilité. Les champs suivants existent maintenant pour une RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Pour plus d’informations, consultez la documentation « Objets ».

Les événements relatifs au Git suivants peuvent à présent s’afficher dans le journal d'audit de l’entreprise. Si vous activez la fonctionnalité et définissez une période de rétention du journal d'audit, les nouveaux événements seront disponibles pour la recherche via l’interface utilisateur et l’API ou l’exportation via JSON ou CSV.

• git.clone
• git.fetch
• git.push

Dû à un grand nombre d’événements GIt enregistrés, nous vous recommandons d’analyser votre stockage de fichiers d’instance et d’évaluer les configurations relatives à l’alerte. Pour plus d’informations, consultez « Configuration du journal d’audit pour votre entreprise ».

Cette mise en production inclut des améliorations apportées aux CODEOWNERS.

• Des erreurs de syntaxe sont à présent exposées lors de l’affichage d’un fichier CODEOWNERS web. Précédemment, lorsqu’une ligne d’un fichier CODEOWNERS avait une erreur de syntaxe, l’erreur pouvait être ignorée ou, dans certains cas, empêcher le chargement du fichier CODEOWNERS entier. GitHub Apps et Actions peuvent accéder à la même liste d’erreurs à l’aide des nouvelles API REST et GraphQL. Pour plus d’informations, consultez « Dépôts » dans la documentation de l’API REST, ou « Objets » dans la documentation de l’API GraphQL.
• Après la création d’une nouvelle demande de tirage ou la poussée de nouvelles modifications vers une demande de tirage brouillon, tous les propriétaires de code invités à une révision sont à présent listés dans la demande de tirage sous « Réviseurs ». Cette fonctionnalité vous offre une vue anticipée de la personne invitée à réviser, une fois la demande de tirage (pull request) marquée comme prête pour la révision.
• Les commentaires dans les fichiers CODEOWNERS s’affichent à présent à la fin de la ligne, et pas seulement sur des lignes dédiées.

Pour plus d’informations, consultez « À propos des propriétaires de code ».

Le bouton Mettre à jour une branche de la page Demande de tirage vous permet de mettre à jour la branche de votre demande de tirage avec les dernières modifications de la branche de base. Ceci est utile pour vérifier que vos modifications sont compatibles avec la version actuelle de la branche de base avant la fusion. Deux améliorations vous proposent désormais des solutions supplémentaires pour garder à jour votre branche.

• Lorsque la branche de rubrique de votre demande de tirage est obsolète par rapport à la branche de base, vous pouvez désormais la mettre à jour en vous rebasant sur la dernière version de la branche de base. Le rebasage s’applique aux modifications issues de votre branche de la dernière version de la branche de base, ce qui abouti à une branche avec un historique linéaire car aucune validation de fusion n’est créée. Pour mettre à jour par rebasage, cliquez sur le menu déroulant à côté du bouton Mettre à jour la branche, cliquez sur Mettre à jour avec rebasage, puis cliquez sur Rebaser la branche. Avant, Mettre à jour la branche effectuait une fusion traditionnelle qui aboutissait toujours à un commit de fusion dans votre branche de demande de tirage. Cette option est encore disponible, mais vous avez désormais le choix. Pour plus d’informations, consultez « Maintien de la synchronisation de votre demande de tirage avec la branche de base ».

• Un nouveau paramètre de dépôt permet d’avoir toujours à disposition le bouton Mettre à jour la branche lorsqu’une branche de rubrique d’une demande de tirage n’est pas à jour avec la branche de base. Avant, ce bouton n’était disponible que lorsque le paramètre de protection de branches Exiger que les branches soient à jour avant la fusion était activé. Les personnes avec un accès administrateur ou mainteneur peuvent gérer le paramètre Toujours suggérer la mise à jour des branches de demandes de tirage à partir de la section Demandes de tirage dans les paramètres du dépôt. Pour plus d’informations, consultez « Gestion des suggestions de mise à jour des branches de demande de tirage ».

  • Remarque : Cette fonctionnalité n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3. La fonctionnalité est disponible dans la version 3.5.4 et ultérieure. [Mise à jour : 16/08/2022]

Vous pouvez désormais configurer des en-têtes HTTP personnalisés pour les appliquer à tous les sites GitHub Pages traités à partir de votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « Configuration de GitHub Pages pour votre entreprise ».

Il est désormais possible d’ignorer les révisions dans la vue des responsabilités en créant un fichier .git-blame-ignore-revs à la racine de votre dépôt. Pour plus d’informations, consultez « Afficher un fichier ».

Un thème clair à contraste élevé, avec un contraste supérieur entre les éléments de premier plan et ceux d'arrière-plan, est à présent en disponibilité générale. Pour plus d’informations, consultez « Gestion de vos paramètres de thème ».

• Remarque : Cette fonctionnalité n’était pas disponible dans GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 et 3.5.3. La fonctionnalité est disponible dans la version 3.5.4 et ultérieure. [Mise à jour : 16/08/2022]

Les propriétaires de référentiels peuvent désormais configurer des règles de protection des étiquettes pour protéger les étiquettes d’un référentiel. Une fois protégé par une règle de protection des étiquettes, les étiquettes correspondant à un modèle de nom spécifié ne peuvent qu’être créées et supprimées par des utilisateurs avec le rôle Maintenir ou Administrateur dans le référentiel. Pour plus d’informations, consultez « Configuration des règles de protection des étiquettes ».

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

Il est désormais possible pour GitHub Apps de charger des éléments de mise en production.

Les exigences minimales pour le stockage racine et la mémoire ont augmenté pour GitHub Enterprise Server 2.10 et 3.0, et sont désormais appliquées à partir de la version 3.5.0.

• Dans la version 2.10, la configuration minimale requise pour le stockage racine est passée de 80 à 200 Go. À partir de la version 3.5.0, les vérifications préalables système échouent si le stockage racine est inférieur à 80 Go.
• Dans la version 3.0, la configuration minimale requise pour la mémoire est passée de 16 à 32 Go. À partir de la version 3.5.0, les vérifications préalables du système échouent si le système dispose de moins de 28 Go de mémoire.

Pour plus d’informations, consultez la configuration minimale requise pour chaque plateforme de déploiement prise en charge dans « Configuration d’une instance GitHub Enterprise Server ». [Mise à jour : 20/06/2022]

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

Pour utiliser le flux d’autorisations des appareils pour OAuth et GitHub Apps, vous devez activer manuellement la fonctionnalité. Cette modification réduit l’utilisation éventuelle d’applications dans des attaques par hameçonnage contre des utilisateurs GitHub Enterprise Server en vérifiant que les intégrateurs sont informés des risques et font un choix conscient pour prendre en charge ce formulaire d’authentification. Si vous possédez ou gérez une application OAuth ou GitHub et que vous souhaitez utiliser le flux d’appareils, vous pouvez l’activer pour votre application via la page des paramètres de l’application. Les points de terminaison de l’API du flux d’appareils répond par le code d’état 400 aux applications qui ont activé cette fonctionnalité. Pour plus d’informations, consultez « Autorisation des applications OAuth ».

La page d’alerte de l’analyse du code affiche désormais toujours l’état de l’alerte et les informations de la branche par défaut. Il existe un nouveau panneau « Branches affectées » sur la barre latérale qui affiche l’état de l’alerte dans d’autres branches. Si l’alerte n’existe pas dans votre branche par défaut, la page d’alerte affiche l’état comme « Dans la branche » ou « dans le demande de tirage (pull request) » pour définir l’emplacement où l’alerte a été vue pour la dernière fois. Cette amélioration facilite la compréhension de l’état des alertes introduites dans votre base de code. Pour plus d’informations, consultez « À propos des alertes d’analyse du code ».

La page des listes d’alertes n’est pas modifiée et peut être filtrée par branch. Vous pouvez utiliser l’API d’analyse du code pour récupérer plus d’informations détaillées sur la branche en ce qui concerne les alertes. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

L’analyse du code affiche à présent les détails de l’origine d’analyse d’une alerte. Si une alerte a plus d’une origine d’analyse, elle est affichée dans la barre latérale « Branches affectées » et dans la chronologie des alertes. Vous pouvez passer la souris sur l’icône d’origine d’analyse dans la barre latérale « Branches affectées » pour consulter l’état de l’alerte dans chaque origine d’analyse. Si une alerte n’a qu’une seule origine d’analyse, aucune information sur les origines d’analyse n’est affichée dans la page d’alerte. Ces améliorations facilitent la compréhension de vos alertes. En particulier, elles vous aident à comprendre celles avec plusieurs origines d’analyse. Ceci est particulièrement utile pour les configurations avec plusieurs configurations d’analyse, tels que les monoréférentiels. Pour plus d’informations, consultez « À propos des alertes d’analyse du code ».

Les listes de référentiels possédées par un utilisateur ou une organisation ont à présent une option de filtre supplémentaire, « Modèles », facilitant la recherche des modèles de référentiels.

GitHub Enterprise Server peut afficher plusieurs formats d’image communs, y compris PNG, JPG, GIF, PSD et SVG et offre plusieurs moyens pour comparer les différences entre des versions. Désormais, lorsque vous évaluez des images ajoutées ou modifiées dans une demande de tirage (pull request), les préversions de ces images sont affichées par défaut. Vous auriez vu, précédemment, un message indiquant que les fichiers binaires ne pouvaient pas être affichés et vous auriez dû basculer l’option « Afficher un Diff riche ». Pour plus d’informations, consultez « Travailler avec des fichiers non basés sur du code ».

Les nouveaux Gists sont maintenant créés avec un nom de branche par défaut, soit main, soit l’autre nom de branche par défaut défini dans vos paramètres utilisateur. Cela correspond au mode de création d’autres référentiels sur GitHub Enterprise Server. Pour plus d’informations, consultez « À propos des branches » et « Gestion du nom de branche par défaut pour vos dépôts ».

Les Gists n’affichent à présent que les 30 derniers commentaires lors du premier affichage. Vous pouvez cliquer sur Charger les commentaires antérieurs... pour en voir plus. Ainsi, les Gists avec plusieurs commentaires peuvent s’afficher plus rapidement. Pour plus d’informations, consultez « Modification et partage de contenu avec des Gists ».

Les pages de paramètres pour les utilisateurs, organisations, référentiels et équipes ont été re-conçues, regroupant les pages de paramètres similaires en sections pour une meilleure architecture et détectabilité des informations. Pour plus d’informations, consultez le journal des modifications de GitHub.

Vous pouvez afficher la description d’une étiquette et une info-bulle en arrêtant ou en passant la souris dessus.

La création et la suppression d’invitations de référentiel, qu’elles soient lancées depuis l’API ou l’interface web, sont maintenant soumises aux limites de débit qui peuvent être activées sur votre instance GitHub Enterprise Server. Pour plus d’informations sur les limites de débit, consultez « Configuration des limites de débit ».

MinIO a annoncé le retrait des Passerelles MinIO à compter du 1 juin 2022. Tandis que la Passerelle MinIO pour NAS continue à être l’un des fournisseurs de stockage pris en charge pour Github Actions et Github Packages, nous vous recommandons de vous déplacer vers le support LTS MinIO pour utiliser le support et les correctifs de bogues à partir de MinIO. Pour plus d’informations sur les limites de débit, consultez « Suppression planifiée de la passerelle MinIO pour GCS, Azure, HDFS » dans le dépôt minio/minio.

GitHub Connect ne fonctionnera plus après le 3 juin pour les instances exécutant GitHub Enterprise Server 3.1 ou versions antérieures, en raison de la modification du format des jetons d’authentification GitHub. Pour continuer à utiliser GitHub Connect, effectuez une mise à niveau vers GitHub Enterprise Server 3.2 ou une version ultérieure. Pour plus d’informations, consultez le blog API GitHub Packages. [Mise à jour : 14/06/2022]

L’exécuteur CodeQL est déconseillé en faveur de l’interface CLI CodeQL. GitHub Enterprise Server 3.4 et versions ultérieures ne prend plus en charge l’exécuteur CodeQL. Cette interruption n’affecte que les utilisateurs qui utilisent l’analyse du code CodeQL dans des systèmes CI/CD tiers. Les utilisateurs GitHub Actions ne sont pas concernés. GitHub recommande fermement aux utilisateurs de migrer vers l’interface CLI CodeQL, qui remplace toutes les fonctionnalités de l’exécuteur CodeQL et propose plusieurs fonctionnalités supplémentaires. Pour plus d’informations, consultez « Migration depuis l’exécuteur CodeQL vers CodeQL CLI ».

Le sélecteur de thème pour GitHub Pages a été supprimé des paramètres des pages. Pour plus d’informations sur la configuration des thèmes des pages GitHub, consultez « Ajout d’un thème à votre site GitHub Pages avec Jekyll ».