Enterprise Server 3.4 release notes

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

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

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

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

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.

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.

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.

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.

Quand un propriétaire d’entreprise active les mises à jour Dependabot, l’instance crée l’ensemble initial des mises à jour plus rapidement.

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

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

Le chemin par défaut de la sortie de ghe-saml-mapping-csv -d est /data/user/tmp au lieu de /tmp. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».

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

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

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

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

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

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.

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

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

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

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

Les dépôts verrouillés pour la migration autorisaient la modification des fichiers dans l’interface utilisateur web.

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

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

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

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

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

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

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

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

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.

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.

Si GitHub Actions a été configuré avec le stockage d’objets blob S3 pour l’instance, le contenu, comme les journaux et les artefacts des exécutions de workflow supprimées ou expirées, restait indéfiniment dans le stockage d’objets blob. L’instance supprimera automatiquement ce contenu lors de la prochaine exécution d’un travail de nettoyage en arrière-plan normal.

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.

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

Dans certains cas, les utilisateurs ne pouvaient pas fusionner une demande de tirage en raison de vérifications d’état inattendues.

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 à tort GitHub.com au lieu du nom d’hôte de l’instance.

Le nettoyage des ressources supprimées et des ressources planifiées à vider au sein d’un dépôt, comme les fichiers LFS, prenait trop de temps.

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.

Pour s’assurer que les administrateurs de sites 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.

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

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

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

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’envoi d’un bundle de support au support GitHub Enterprise à l’aide de ghe-support-upload, l’option -t n’associait pas correctement le bundle chargé au ticket spécifié.

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

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

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

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

Après la mise à niveau vers GitHub Enterprise Server 3.4, 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.

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.

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.

Lors de l’ajout d’un membre à une organisation, une invitation d’essai SAML SSO erronée apparaissait.

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

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

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

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

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

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

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

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

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.

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

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

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

Les archives de migration pour les référentiels et les exportations d’archives pour les comptes d’utilisateurs comprennent des réactions à la version.

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.

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.

Dans certains cas, les workflows GitHub Actions programmés pouvaient être désactivés.

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.

L’utilitaire en ligne de commande ghe-set-password démarre automatiquement les services nécessaires quand l’instance démarre en mode de 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.

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.

Un problème de rendu pouvait affecter la liste déroulante permettant de filtrer les alertes d’analyse des secrets dans un référentiel.

Amélioration des performances des mises à jour des versions de Dependabot après leur première activation.

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

La création ou la mise à jour d’exécutions ou de suites de contrôles pouvait renvoyer 500 Internal Server Error si la valeur de certains champs, comme le nom, était trop longue.

Lors du déploiement de nœuds de serveur de cache, il est désormais 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.

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.

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

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.

MOYEN : Un problème de sécurité a été identifié dans le programme de résolution nginx. Un attaquant pouvait falsifier les paquets UDP provenant du serveur DNS, et provoquer le remplacement d’un octet de mémoire, ce qui entraînait des plantages de processus de travail ou d’autres impacts potentiellement dommageables. La vulnérabilité s’est vu affecter l’identifiant CVE-2021-23017.

Mise à jour des actions actions/checkout@v2 et actions/checkout@v3 pour corriger les nouvelles vulnérabilités annoncées dans le billet de blog Git sur l’application de la sécurité.

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

Dans certaines topologies de clusters, la commande ghe-cluster-status laissait derrière elle des répertoires vides dans /tmp.

SNMP enregistrait incorrectement un nombre élevé de messages d’erreur Cannot statfs dans syslog.

Lors de l’ajout de modèles personnalisés et de la fourniture de chaînes de test non UTF8, la mise en évidence des correspondances était incorrecte.

Les utilisateurs LDAP avec un caractère de soulignement (_) dans leur nom d’utilisateur peuvent maintenant se connecter avec succès.

Pour les instances configurées avec l’authentification SAML et le repli intégré activé, les utilisateurs intégrés restaient bloqués dans une boucle de connexion lorsqu’ils tentaient de se connecter à partir de la page générée après la déconnexion.

Après avoir activé les assertions chiffrées SAML avec Azure comme fournisseur d’identité, la page de connexion échouait avec une erreur 500.

Les préférences de raccourci clavier des caractères n’étaient pas respectées.

Les tentatives d’affichage de la sortie git fsck de la page /stafftools/repositories/:owner/:repo/disk échouaient avec 500 Internal Server Error.

Lors de l’utilisation d’assertions chiffrées SAML, certaines assertions ne marquaient pas correctement les clés SSH comme vérifiées.

Les vidéos chargées pour émettre des commentaires ne s’affichaient pas correctement.

Lors de l’utilisation de GitHub Enterprise Importer pour importer un référentiel, l’importation de certains numéros échouait en raison d’événements de chronologie du projet incorrectement configurés.

Quand vous utilisiez ghe-migrator, la migration ne parvenait pas à importer les pièces jointes de type fichier vidéo dans les problèmes et les demandes de tirage.

La page Versions retournait l’erreur 500 quand le dépôt contenait des étiquettes comportant des caractères non ASCII. [Mise à jour : 10/06/2022]

Les mises à jour échouaient parfois lors de la migration des données du graphe des dépendances. [Mise à jour : 30/06/2022]

Dans les configurations à haute disponibilité, précision du fait que la page de présentation de la réplication dans la console de gestion affiche uniquement la configuration actuelle de la réplication, et non l’état actuel de la réplication.

Le délai d’allocation de Nomad pour le graphe des dépendances a été augmenté pour assurer que les migrations post-mise à jour puissent se terminer.

Lorsque vous activez GitHub Packages, précision que l’utilisation d’un jeton de signature d’accès partagé (SAP) comme chaîne de connexion n’est pas prise en charge actuellement.

Les packs de support incluent désormais le nombre de lignes des tables stockées dans MySQL.

Lorsque nous déterminons les réseaux de référentiels sur lesquels nous devons planifier la maintenance, nous ne comptons plus la taille des objets inaccessibles.

Le champ de réponse run_started_at est désormais inclus dans l’API d’exécutions de workflow et la charge utile du webhook d’événement workflow_run.

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

Résolution d’une régression qui pouvait entraîner des échecs constants dans la récupération des artefacts et le téléchargement des archives des journaux pour GitHub Actions. Dans certaines circonstances, nous cessions de résoudre les URL pour les communications internes qui utilisaient localhost, et utilisions de manière incorrecte le nom d’hôte de l’instance.

Lorsqu’un fichier de manifeste était supprimé d’un référentiel, le manifeste n’était pas supprimé de la page « Graphe de dépendances » du référentiel.

La mise à niveau des nœuds d’une paire à haute disponibilité avec un package de mise à niveau pouvait faire entrer Elasticsearch dans un état incohérent dans certains cas.

Les fichiers journaux permutés avec l’extension .backup s’accumulaient dans les répertoires contenant les journaux du système.

Dans certaines topologies de cluster, les utilitaires de ligne de commande ghe-spokesctl et ghe-btop ne pouvaient pas s’exécuter.

Les indices d’Elasticsearch pouvaient être dupliqués lors d’une mise à niveau de package, en raison d’un service elasticsearch-upgrade s’exécutant plusieurs fois en parallèle.

Les serveurs de cache du référentiel pouvaient servir des données provenant d’emplacements hors cache, même si ces données étaient disponibles dans l’emplacement du cache local.

Lors de la conversion d’un compte d’utilisateur en compte d’organisation, si le compte d’utilisateur était propriétaire du compte d’entreprise GitHub Enterprise Server, l’organisation convertie apparaissait de manière incorrecte dans la liste des propriétaires d’entreprise.

La page /stafftools/users/ip_addresses/:address répondait par 500 Internal Server Error lors de la tentative d’affichage de la page pour une adresse IPv6.

La création d’un jeton OAuth d’emprunt d’identité à l’aide de l’API REST Administration d’entreprise entraînait une erreur quand une intégration correspondant à l’ID d’application OAuth existait déjà.

Ajout de la prise en charge des noms de domaine de réplica qui comportent plus de 63 caractères.

Les erreurs de configuration qui interrompent l’exécution d’une application de configuration sont maintenant affichées dans le terminal en plus du journal de configuration.

Si les fonctionnalités de GitHub Advanced Security sont activées sur votre instance, les performances des travaux en arrière-plan ont été améliorées lors du traitement des lots pour les contributions au référentiel.

Sur une instance fraîchement configurée de GitHub Enterprise Server sans aucun utilisateur, un attaquant pourrait créer le premier utilisateur administrateur.

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

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

Lorsque l’option « Les utilisateurs peuvent effectuer des recherches sur GitHub.com » est activée avec GitHub Connect, les problèmes des référentiels privés et internes ne sont pas inclus dans les résultats de recherche de GitHub.com.

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

Les limites de ressources propres au traitement des hooks de pré-réception peuvent entraîner l’échec de certains d’entre eux.

Après avoir enregistré un exécuteur auto-hébergé avec le paramètre --ephemeral à plus d’un niveau (par exemple entreprise et organisation), l’exécuteur peut rester bloqué dans un état d’inactivité et nécessiter un nouvel enregistrement. [Mise à jour : 17/06/2022]

Après la mise à niveau vers GitHub Enterprise Server 3.4, des versions peuvent sembler manquer dans les référentiels. Cela peut se produire lorsque les migrations d’index Elasticsearch requises n’ont pas été effectuées avec succès.

Dans certains cas, les clients GitHub Advanced Security qui effectuent une mise à niveau vers GitHub Enterprise Server 3.5 ou version ultérieure peuvent remarquer que les alertes de l’analyse secrète sont manquantes dans l’interface utilisateur web et l’API REST. Pour vous assurer que les alertes restent visibles, n’ignorez pas la version 3.4 lorsque vous effectuez une mise à niveau d’une version antérieure vers la version 3.5 ou ultérieure. Un correctif est disponible dans les versions de patch 3.5.5 et 3.6.1.

Pour planifier une mise à niveau via la version 3.4, consultez l’Assistant Mise à niveau. [Mise à jour : 01/09/2022]

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

GitHub Enterprise Server 3.0 a été mis hors service le 16 février 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour bénéficier d’un meilleur niveau de performance, d’une sécurité accrue et de nouvelles fonctionnalités, mettre à niveau vers la version le plus récente de GitHub Enterprise Server dès que possible.

GitHub Enterprise Server 3.1 a été mis hors service le 3 juin 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour bénéficier d’un meilleur niveau de performance, d’une sécurité accrue et de nouvelles fonctionnalités, mettre à niveau vers la version le plus récente de GitHub Enterprise Server dès que possible.

Depuis GitHub Enterprise Server 3.3, GitHub Enterprise Server sur XenServer est déprécié et n’est plus pris en charge. Contactez le support GitHub pour toute question ou préoccupation.

En raison d’une faible utilisation, nous avons déprécié la préversion de l’API Références de contenu dans GitHub Enterprise Server 3.4. L’API était précédemment accessible avec l’en-tête corsair-preview. Les utilisateurs peuvent continuer à accéder à des URL externes sans cette API. Toutes les utilisations enregistrées de l’API Références de contenu ne recevront plus de notification par webhook pour les URL de votre ou vos domaines enregistrés, et nous ne renverrons plus de codes de réponse valides pour les tentatives de mise à jour des attachements de contenu existants.

La préversion de l’API Codes de conduite, qui était accessible avec l’en-tête scarlet-witch-preview, est dépréciée et n’est plus accessible dans GitHub Enterprise Server 3.4. Nous vous recommandons plutôt d’utiliser le point de terminaison « Obtenir les métriques de profil de communauté » pour récupérer des informations sur le code de conduite d’un dépôt. Pour plus d’informations, consultez « Avis de dépréciation : préversion de l’API Codes de conduite » dans le journal des modifications de GitHub.

À compter de GitHub Enterprise Server 3.4, la version dépréciée des points de terminaison d’API d’application OAuth est supprimée. Si vous rencontrez des messages d’erreur 404 sur ces points de terminaison, convertissez votre code dans des versions de l’API d’application OAuth qui n’ont pas access_tokens dans l’URL. Nous avons également désactivé l’utilisation de l’authentification de l’API avec des paramètres de requête. Nous vous recommandons plutôt d’utiliser l’authentification API dans l’en-tête de requête.

L’exécuteur CodeQL est déprécié dans GitHub Enterprise Server 3.4 et n’est plus pris en charge. Cette dépréciation ne concerne que les utilisateurs qui utilisent l’analyse du code de CodeQL dans des systèmes CI/CD tiers, les utilisateurs de GitHub Actions ne sont pas concernés. Nous recommandons vivement aux clients de migrer vers l’interface CLI de CodeQL, qui remplace toutes les fonctionnalités de l’exécuteur CodeQL. Pour plus d’informations, consultez le journal des modifications de GitHub.

À partir de GitHub Enterprise Server 3.1, la prise en charge des extensions de cache binaire propriétaires de GitHub est supprimée progressivement. Ces extensions sont dépréciées dans GitHub Enterprise Server 3.3 et ultérieur.

Tous les dépôts qui étaient déjà présents et actifs sur votre instance GitHub Enterprise Server version 3.1 ou 3.2 ont été automatiquement mis à jour.

Les dépôts qui n’étaient pas présents et actifs avant la mise à niveau vers GitHub Enterprise Server 3.3 peuvent ne pas fonctionner de manière optimale tant qu’une tâche de maintenance du dépôt n’est pas correctement exécutée.

Pour lancer manuellement une tâche de maintenance de dépôt, accédez à https://<hostname>/stafftools/repositories/<owner>/<repository>/network pour chaque dépôt affecté et cliquez sur le bouton Planification.

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

MOYENNE : Une vulnérabilité de traversée de chemin qui permettait de contourner les protections CSRF a été identifiée dans GitHub Enterprise Server Management Console. Cette vulnérabilité affectait toutes les versions de GitHub Enterprise Server antérieures à la version 3.5, et a été corrigée dans les versions 3.1.19, 3.2.11, 3.3.6 et 3.4.1. Cette vulnérabilité a été signalée via le programme GitHub dans le cadre du programme Bug Bounty et s’est vu affecter le numéro CVE-2022-23732.

MOYEN : Une vulnérabilité de dépassement d’entier a été identifiée dans la branche 1.x et la branche 2.x de yajil. Elle entraîne une altération de la mémoire du tas pour les entrées volumineuses (environ 2 Go). Cette vulnérabilité a été signalée en interne et s’est vu affecter le numéro CVE-2022-24795.

Les packs de support pouvaient inclure des fichiers sensibles si GitHub Actions était activé.

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

L’exécution d’un workflow peut ne pas se terminer s’il utilise des actions composites.

Lors de l’activation de Dependabot, une erreur faisait que certains avis de sécurité étaient temporairement lus comme n’étant plus applicables.

Les processus Minio avaient une utilisation élevée de l’UC si une ancienne option de configuration était présente après la mise à niveau de GitHub Enterprise Server.

Les options permettant d’activer TLS 1.0 et TLS 1.1 dans les paramètres de confidentialité de la console de gestion étaient affichées alors que la suppression de ces versions de protocole avait eu lieu dans une version antérieure.

Dans un environnement HA, la configuration de la réplication MSSQL pouvait nécessiter des étapes manuelles supplémentaires après avoir activé GitHub Actions pour la première fois.

Un sous-ensemble de fichiers de configuration internes est mis à jour de manière plus fiable après un correctif.

Le script ghe-run-migrations ne parvenait pas toujours à générer correctement les noms des certificats temporaires.

Les hooks de pré-réception qui utilisaient gpg --import arrivaient à expiration en raison de privilèges syscall insuffisants.

Dans certaines topologies de clusters, les informations de livraison des webhooks n’étaient pas disponibles.

Le graphique de déploiement GitHub Actions affichait une erreur lors du rendu d’un travail en attente.

Les contrôles d’intégrité d’Elasticsearch n’autorisaient pas un état de cluster jaune lors de l’exécution de migrations.

Lors de l’utilisation de l’API Migrations, les travaux d’exportation mis en file d’attente n’étaient pas traités.

Les référentiels affichaient un onglet Discussions non fonctionnel dans l’interface web.

Les organisations créées à la suite de la transformation par un utilisateur de son compte d’utilisateur en un compte d’organisation n’étaient pas été ajoutées au compte d’entreprise global.

Les tâches de synchronisation des utilisateurs LDAP échouaient lorsqu’elles tentaient de synchroniser des clés GPG qui avaient été synchronisées précédemment.

Les liens vers les pages inaccessibles ont été supprimés.

Certaines instances subissaient une utilisation élevée de l’UC en raison de la mise en file d’attente d’un grand nombre de travaux d’arrière-plan inutiles.

Les référentiels vides ne se synchronisaient pas correctement avec les serveurs de cache.

L’ajout d’une équipe en tant que réviseur d’une demande de tirage pouvait parfois indiquer le nombre incorrect de membres de cette équipe.

Le point de terminaison d’API de suppression d’un membre d’équipe répondait par une erreur lors de la tentative de suppression d’un membre géré en externe via un groupe SCIM.

Un grand nombre d’utilisateurs dormants pouvait faire échouer une configuration GitHub Connect.

La page « Inscriptions de fonctionnalités & bêta » dans l’interface web d’administration du site était incorrectement disponible.

Le lien « Mode Administrateur du site » dans le pied de page du site ne changeait pas d’état quand on cliquait dessus.

Une exportation à partir de GitHub.com ou avec ghe-migrator n’incluait pas les pièces jointes des demandes de tirage.

Les limites de connexion de Memcached ont été augmentées pour mieux s’adapter aux topologies des grands clusters.

L’API du graphe des dépendances fonctionnait auparavant avec un port défini de manière statique.

Le nombre de partitions par défaut pour les paramètres de partitionnement d’Elasticsearch liés aux clusters a été mis à jour.

L’API Migrations génère désormais des exportations de dépôts.

Lors du filtrage des membres d’entreprise par rôle d’organisation sur la page « Personnes », le texte des éléments du menu déroulant a été amélioré.

Les rôles des équipes « Triage » et « Maintain » sont préservés lors des migrations de référentiels.

Les performances ont été améliorées pour les requêtes web effectuées par les propriétaires d’entreprise.

Sur une instance fraîchement configurée de GitHub Enterprise Server sans aucun utilisateur, un attaquant pourrait créer le premier utilisateur administrateur.

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

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

Lorsque l’option « Les utilisateurs peuvent effectuer des recherches sur GitHub.com » est activée avec GitHub Connect, les problèmes des référentiels privés et internes ne sont pas inclus dans les résultats de recherche de GitHub.com.

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

Les limites de ressources propres au traitement des hooks de pré-réception peuvent entraîner l’échec de certains d’entre eux.

Après avoir enregistré un exécuteur auto-hébergé avec le paramètre --ephemeral à plus d’un niveau (par exemple entreprise et organisation), l’exécuteur peut rester bloqué dans un état d’inactivité et nécessiter un nouvel enregistrement. [Mise à jour : 17/06/2022]

Lors de l’utilisation d’assertions chiffrées SAML avec GitHub Enterprise Server 3.4.0 et 3.4.1, un nouvel attribut XML WantAssertionsEncrypted dans SPSSODescriptor contenait un attribut non valide pour les métadonnées SAML. Les IdP qui utilisent ce point de terminaison de métadonnées SAML peuvent rencontrer des erreurs lors de la validation du schéma XML des métadonnées SAML. Un correctif sera disponible dans la prochaine version du patch. [Mise à jour : 11/04/2022]

Pour contourner ce problème, vous pouvez prendre l’une des deux mesures suivantes.

• Reconfigurez l’IdP en chargeant une copie statique des métadonnées SAML sans l’attribut WantAssertionsEncrypted.
• Copiez les métadonnées SAML, supprimez l’attribut WantAssertionsEncrypted, hébergez-les sur un serveur web et reconfigurez l’IdP pour qu’il pointe vers cette URL.

Dans certains cas, les clients GitHub Advanced Security qui effectuent une mise à niveau vers GitHub Enterprise Server 3.5 ou version ultérieure peuvent remarquer que les alertes de l’analyse secrète sont manquantes dans l’interface utilisateur web et l’API REST. Pour vous assurer que les alertes restent visibles, n’ignorez pas la version 3.4 lorsque vous effectuez une mise à niveau d’une version antérieure vers la version 3.5 ou ultérieure. Un correctif est disponible dans les versions de patch 3.5.5 et 3.6.1.

Pour planifier une mise à niveau via la version 3.4, consultez l’Assistant Mise à niveau. [Mise à jour : 01/09/2022]

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

GitHub Enterprise Server 3.0 a été mis hors service le 16 février 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour bénéficier d’un meilleur niveau de performance, d’une sécurité accrue et de nouvelles fonctionnalités, mettre à niveau vers la version le plus récente de GitHub Enterprise Server dès que possible.

GitHub Enterprise Server 3.1 a été mis hors service le 3 juin 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour bénéficier d’un meilleur niveau de performance, d’une sécurité accrue et de nouvelles fonctionnalités, mettre à niveau vers la version le plus récente de GitHub Enterprise Server dès que possible.

Depuis GitHub Enterprise Server 3.3, GitHub Enterprise Server sur XenServer est déprécié et n’est plus pris en charge. Contactez le support GitHub pour toute question ou préoccupation.

En raison d’une faible utilisation, nous avons déprécié la préversion de l’API Références de contenu dans GitHub Enterprise Server 3.4. L’API était précédemment accessible avec l’en-tête corsair-preview. Les utilisateurs peuvent continuer à accéder à des URL externes sans cette API. Toutes les utilisations enregistrées de l’API Références de contenu ne recevront plus de notification par webhook pour les URL de votre ou vos domaines enregistrés, et nous ne renverrons plus de codes de réponse valides pour les tentatives de mise à jour des attachements de contenu existants.

La préversion de l’API Codes de conduite, qui était accessible avec l’en-tête scarlet-witch-preview, est dépréciée et n’est plus accessible dans GitHub Enterprise Server 3.4. Nous vous recommandons plutôt d’utiliser le point de terminaison « Obtenir les métriques de profil de communauté » pour récupérer des informations sur le code de conduite d’un dépôt. Pour plus d’informations, consultez « Avis de dépréciation : préversion de l’API Codes de conduite » dans le journal des modifications de GitHub.

À compter de GitHub Enterprise Server 3.4, la version dépréciée des points de terminaison d’API d’application OAuth est supprimée. Si vous rencontrez des messages d’erreur 404 sur ces points de terminaison, convertissez votre code dans des versions de l’API d’application OAuth qui n’ont pas access_tokens dans l’URL. Nous avons également désactivé l’utilisation de l’authentification de l’API avec des paramètres de requête. Nous vous recommandons plutôt d’utiliser l’authentification API dans l’en-tête de requête.

L’exécuteur CodeQL est déprécié dans GitHub Enterprise Server 3.4 et n’est plus pris en charge. Cette dépréciation ne concerne que les utilisateurs qui utilisent l’analyse du code de CodeQL dans des systèmes CI/CD tiers, les utilisateurs de GitHub Actions ne sont pas concernés. Nous recommandons vivement aux clients de migrer vers l’interface CLI de CodeQL, qui remplace toutes les fonctionnalités de l’exécuteur CodeQL. Pour plus d’informations, consultez le journal des modifications de GitHub.

À partir de GitHub Enterprise Server 3.1, la prise en charge des extensions de cache binaire propriétaires de GitHub est supprimée progressivement. Ces extensions sont dépréciées dans GitHub Enterprise Server 3.3 et ultérieur.

Tous les dépôts qui étaient déjà présents et actifs sur votre instance GitHub Enterprise Server version 3.1 ou 3.2 ont été automatiquement mis à jour.

Les dépôts qui n’étaient pas présents et actifs avant la mise à niveau vers GitHub Enterprise Server 3.3 peuvent ne pas fonctionner de manière optimale tant qu’une tâche de maintenance du dépôt n’est pas correctement exécutée.

Pour lancer manuellement une tâche de maintenance de dépôt, accédez à https://<hostname>/stafftools/repositories/<owner>/<repository>/network pour chaque dépôt affecté et cliquez sur le bouton Planification.

Les clients GitHub Advanced Security peuvent à présent utiliser l’API REST pour récupérer des informations sur la validation des secrets détectées dans des analyses de dépôt privé. Le nouveau point de terminaison retourne les détails de la première détection d’un secret au sein d’un fichier, y compris l’emplacement du secret et le SHA de commit. Pour plus d’informations, consultez « Analyse de secrets » dans la documentation de l’API REST.

Les propriétaires d’entreprise et d’organisation peuvent à présent exporter leurs données d’utilisation de licences GitHub Advanced Security dans un fichier CSV. Les données de facturation Advanced Security peuvent également être récupérées via des points de terminaison de la facturation dans l’API REST. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Vous pouvez à présent réutiliser des workflows entiers comme s’il s’agissait d’une action. Cette fonctionnalité est disponible dans une version bêta publique. Au lieu de copier et coller des définitions de workflow dans des dépôts, vous pouvez maintenant référencer un workflow existant avec une simple ligne de configuration. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Dependabot est désormais disponible dans GitHub Enterprise Server 3.4 en tant que bêta publique, offrant à la fois des mises à jour de version et des mises à jour de sécurité pour plusieurs écosystèmes populaires. Dependabot sur GitHub Enterprise Server nécessite GitHub Actions et un pool d’exécuteurs auto-hébergés configurés pour l’utilisation de Dependabot. Dependabot sur GitHub Enterprise Server nécessite également que GitHub Connect et Dependabot soient activés par un administrateur. Les commentaires et suggestions sur la version bêta peuvent être partagés dans Discussion GitHub sur les commentaires Dependabot. Pour plus d’informations et pour essayer la version bêta, consultez « Configuration des mises à jour de la version et de la sécurité de Dependabot pour votre entreprise ».

Si vous utilisez l’authentification SAML pour GitHub Enterprise Server, vous pouvez désormais configurer des assertions chiffrées à partir de votre fournisseur d’identité pour améliorer la sécurité. Les assertions chiffrées ajoutent une couche de chiffrement supplémentaire quand votre fournisseur d’identité transmet des informations à votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « Utilisation de SAML ».

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]

Les utilisateurs peuvent maintenant choisir à quel nombre d’espaces est égal une tabulation, en définissant la taille de tabulation qu’ils préfèrent dans les paramètres « Apparence » de leur compte d’utilisateur. Tout code mis en retrait avec une tabulation s’affichera dans cette taille de tabulation.

L’enregistrement de la connexion de données GitHub Connect comprend désormais un décompte du nombre d’utilisateurs actifs et dormants et la période de dormance configurée.

Vous pouvez maintenant permettre aux utilisateurs d’accéder aux liens spécifiques à l’entreprise en ajoutant des pieds de page personnalisés à GitHub Enterprise Server. Pour plus d’informations, consultez « Configuration de pieds de page personnalisés ».

WireGuard, utilisé pour sécuriser la communication entre les instances GitHub Enterprise Server dans une configuration à haute disponibilité, a été migré vers l’implémentation de noyau.

Les propriétaires d’organisation peuvent désormais se désabonner des e-mails de notification lorsque de nouvelles clés de déploiement sont ajoutées aux dépôts appartenant à leur organisation. Pour plus d’informations, consultez « Configuration des notifications ».

Les e-mails de notification des problèmes et demandes de tirage créés récemment incluent à présent (Issue #xx) ou (PR #xx) dans l’objet de l’e-mail, ce qui vous permet de reconnaître et de filtrer les e-mails qui font référence à ces types de problèmes.

Les organisations peuvent à présent afficher le fichier README.md dans la Vue d’ensemble de leur profil. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les membres des organisations peuvent désormais afficher une liste des propriétaires de leur entreprise sous l’onglet « Personnes » de l’organisation. La liste des propriétaires de l’entreprise est à présent accessible à l’aide de l’API GraphQL. Pour plus d’informations, consultez le champ « enterpriseOwners » sous l’objet Organisation dans la documentation de l’API GraphQL.

Une section « Gérer l’accès » est à présent affichée dans la page « Collaborateurs et équipes » dans les paramètres de votre dépôt. La nouvelle section permet aux administrateurs de dépôt de voir et de gérer plus facilement qui a accès à leur dépôt et le niveau d’accès accordé à chaque utilisateur. Les administrateurs peuvent maintenant :

• Rechercher qui a accès au dépôt parmi tous les membres, équipes et collaborateurs.
• Voir quand les membres ont des attributions de rôle mixtes, accordées directement à eux-mêmes ou indirectement via un équipe. Ces informations sont visualisées par le biais d’un nouvel avertissement « rôles mixtes », qui affiche le rôle de niveau le plus élevé si leur niveau de privilège est supérieur à celui de leur rôle attribué.
• Gérer l’accès aux dépôts populaires de manière fiable avec un système de pagination et moins de délais d’expiration lorsque des grands groupes d’utilisateurs y ont accès.

GitHub Enterprise Server 3.4 présente des améliorations de l’expérience d’invitation à des dépôts, telles que des notifications pour des invitations à des dépôts privés, une invite d’interface utilisateur lorsque vous accédez à un dépôt privé pour lequel vous avez une invitation en attente et une bannière dans une page de présentation de dépôt public quand une invitation est en attente.

Vous pouvez désormais utiliser des préfixes à un caractère pour des liens automatiques personnalisés. Les préfixes de lien automatique autorisent désormais aussi l’utilisation des caractères ., -, _, +, =, :, / et #, ainsi que les caractères alphanumériques. Pour plus d’informations sur les liens automatiques personnalisés, consultez « Configuration des liens automatiques pour référencer des ressources externes ».

Un fichier CODE_OF_CONDUCT.md à la racine d’un dépôt est à présent mis en évidence sur la barre latérale « À propos de » de la page de présentation du dépôt.

GitHub Enterprise Server 3.4 présente des améliorations de l’interface utilisateur Mise en production, notamment des notes de publication générées automatiquement qui affichent un récapitulatif de toutes les demandes de tirage pour une mise en production donnée. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Lorsqu’une mise en production est publiée, une liste d’avatars est maintenant affichée en bas de la mise en production. Les avatars de tous les comptes d’utilisateur mentionnés dans les notes de publication sont affichés. Pour plus d’informations, consultez « Gestion des mises en production dans un dépôt ».

Vous pouvez dès à présent utiliser la nouvelle page de paramètres « Accessibilité » pour gérer vos raccourcis clavier. Vous pouvez choisir de désactiver les raccourcis clavier qui utilisent uniquement des caractères uniques comme S, G C et . (la touche de point). Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Vous pouvez désormais choisir d’utiliser une police à largeur fixe dans des champs activés par Markdown, notamment des commentaires sur les problèmes et des descriptions de demandes de tirage (pull request). Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Vous pouvez à présent coller une URL sur du texte sélectionné pour créer rapidement un lien Markdown. Ceci fonctionne dans tous les champs activés par Markdown, tels que des commentaires sur des problèmes et des descriptions de demandes de tirage (pull request). Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Vous pouvez désormais ajouter une URL d’image avec un thème, tel que #gh-dark-mode-only, pour définir l’affichage de l’image Markdown dans une visionneuse. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Quand vous créez ou modifiez un fichier gist avec l’extension de fichier de Markdown (.md), vous pouvez maintenant utiliser l’onglet « Prévisualiser » ou « Prévisualiser les changements » pour afficher un rendu Markdown du contenu du fichier. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Quand vous entrez le nom d’un utilisateur GitHub dans des problèmes, des demandes de tirage et des discussions, le suggesteur @mention classe désormais les participants existants plus haut que les autres utilisateurs GitHub, de sorte que l’utilisateur que vous cherchez a plus de chances de se trouver dans la liste.

Les langues écrites de droite à gauche sont à présent prises en charge de manière native dans les fichiers, problèmes, demandes de tirage, discussions et commentaires Markdown.

Le paramètre des différences dédié à masquer des modifications d’espaces dans l’onglet « Fichiers modifiés » de la demande de tirage (pull request) est maintenant maintenu pour votre compte d'utilisateur et pour cette demande de tirage (pull request). Le paramètre choisi est automatiquement réappliqué si vous vous éloignez de la page puis revenez à l’onglet « Fichiers modifiés » de la même demande de tirage (pull request).

Lorsque vous utilisez une affectation automatique pour des révisions du code de demande de tirage (pull request), vous pouvez désormais choisir de n’informer que les membres de l’équipe requis, indépendamment de vos paramètres d’affectation automatiques. Ce paramètre est utile dans les scénarios où un grand nombre d’utilisateurs sont affectés automatiquement alors que les utilisateurs ne nécessitent pas tous une notification. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les administrateurs d’organisation et de dépôt peuvent maintenant déclencher des webhooks pour écouter les changements apportés aux règles de protection des branches dans leurs dépôts. Pour plus d’informations, consultez l’événement « branch_protection_rule » dans la documentation sur les événements et charges utiles des webhooks.

Lors de la configuration de branches protégées, vous pouvez à présent mettre en place qu’une vérification d’état obligatoire soit fournie par une GitHub App spécifique. Si une autre application vient à fournir un état, ou un utilisateur via un état de commit, la fusion est empêchée. Cela garantit que toutes les modifications sont validées par l’application concernée. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Seuls les utilisateurs disposant d’autorisations d’administrateur peuvent désormais renommer les branches protégées et modifier les règles de protection des branches. Avant, à l’exception de la branche par défaut, un collaborateur pouvait renommer une branche et, par conséquent, toutes les règles de protection des branches sans caractère générique qui s’appliquaient à cette branche étaient également renommées. Pour plus d’informations, consultez « Renommage d’une branche » et « Gestion d’une règle de protection de branche ».

Les administrateurs peuvent désormais autoriser les utilisateurs et les équipes spécifiques à dépasser les exigences des demandes de tirage (pull request). Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les administrateurs peuvent désormais autoriser uniquement des utilisateurs et des équipes spécifiques à forcer une poussée vers un dépôt. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Lorsque des demandes de tirage sont nécessaires pour tous les changements d’une branche protégée, les administrateurs peuvent désormais choisir si des révisions approuvées sont aussi une condition requise. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les workflows GitHub Actions déclenchés par Dependabot pour les événements create, deployment et deployment_status reçoivent désormais systématiquement un jeton en lecture seule et pas de secrets. De la même manière, les workflows déclenchés par Dependabot pour l’événement pull_request_target sur les demandes de tirage (pull request) où la référence de base a été créée par Dependabot, reçoivent maintenant toujours un jeton en lecture seule sans secrets. Ces changements ont pour but d’empêcher du code potentiellement dangereux de s’exécuter dans un workflow privilégié. Pour plus d’informations, consultez « Automatisation de Dependabot avec GitHub Actions ».

Les exécutions de workflow sur les événements push et pull_request déclenchés par Dependabot respectent à présent les autorisations spécifiées dans vos workflows, ce qui vous permet de contrôler votre façon de gérer les mises à jour de dépendances automatiques. Les autorisations de jeton par défaut resteront en lecture seule. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les workflows GitHub Actions déclenchés par Dependabot se verront désormais envoyer les secrets Dependabot. Vous pouvez effectuer des tirages depuis des registres de packages privés dans votre CI en utilisant les mêmes secrets que vous avez configurés pour que Dependabot les utilise, ce qui améliore le fonctionnement entre GitHub Actions et Dependabot. Pour plus d’informations, consultez « Automatisation de Dependabot avec GitHub Actions ».

Vous pouvez maintenant gérer des groupes d’exécuteurs et voir l’état de vos exécuteurs auto-hébergés dans les nouvelles pages Exécuteurs et Groupes d’exécuteurs de l’interface utilisateur. La page de paramètres Actions de votre dépôt ou organisation affiche désormais une vue récapitulative de vos exécuteurs et vous permet d’explorer un exécuteur spécifique pour le modifier ou voir le travail qu’il est en train d’exécuter. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Les auteurs d’actions peuvent maintenant exécuter leur action en Node.js 16 en spécifiant runs.using comme node16 dans le fichier action.yml de l’action. Cela est ajouté au support Node.js 12 existant ; les actions peuvent continuer à spécifier runs.using: node12 pour utiliser le runtime Node.js 12.

Pour les workflows déclenchés manuellement, GitHub Actions prend désormais en charge les types d’entrée choice, boolean et environment en plus du type par défaut string. Pour plus d’informations, consultez « on.workflow_dispatch.inputs ».

Les actions écrites en YAML, également appelées actions composites, prennent désormais en charge les conditionnels if. Ceci vous permet d’empêcher l’exécution d’étapes spécifiques, sauf si une condition a été remplie. Comme pour les étapes définies dans les workflows, vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel.

Le comportement de l’ordre de recherche des exécuteurs auto-hébergés a changé : le premier exécuteur correspondant disponible, quel que soit le niveau, exécute le travail dans tous les cas. Ceci permet d’envoyer des travaux plus rapidement aux exécuteurs auto-hébergés, en particulier pour les organisations et les entreprises qui ont beaucoup d’exécuteurs auto-hébergés. Avant, lors de l’exécution d’un travail qui nécessitait un exécuteur auto-hébergé, GitHub Actions recherchait des exécuteurs auto-hébergés dans l’ordre suivant : le dépôt, l’organisation et l’entreprise.

Les étiquettes des exécuteurs auto-hébergés GitHub Actions peuvent désormais être listées, ajoutées et supprimées à l’aide de l’API REST. Pour plus d’informations sur l’utilisation des nouvelles API au niveau d’un dépôt, d’une organisation ou d’une entreprise, consultez « Dépôts », « Organisations » et « Entreprises » dans la documentation de l’API REST.

Le graphe des dépendances prend désormais en charge la détection des dépendances Python dans les dépôts qui utilisent le gestionnaire de package Poetry. Les dépendances sont détectées à partir des fichiers manifeste pyproject.toml et poetry.lock.

Lorsque vous configurez les mises à jour de sécurité et de version de Dependabot sur GitHub Enterprise Server, nous vous recommandons d’activer également Dependabot dans GitHub Connect. Cela permettra à Dependabot de récupérer une liste des dépendances et des vulnérabilités mise à jour à partir de GitHub.com, en réclamant des informations, notamment les journaux des modifications des mises en production publiques du code open source duquel vous dépendez. Pour plus d’informations, consultez « Activation du graphe de dépendances et des alertes Dependabot pour votre entreprise ».

Les alertes Dependabot alerts peuvent à présent être ignorées à l’aide de l’API GraphQL. Pour plus d’information, consultez la mutation « dismissRepositoryVulnerabilityAlert » dans la documentation de l’API GraphQL.

L’interface CLI de CodeQL prend désormais en charge l’aide des requêtes rendues en Markdown dans les fichiers SARIF afin de pouvoir lire le texte de l’aide dans l’interface utilisateur de code scanning lorsque la requête génère une alerte. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

L’interface CLI de CodeQL et l’extension Visual Studio Code prennent désormais en charge la génération de bases de données et l’analyse de code sur des machines équipées d’Apple Silicon comme Apple M1. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

La profondeur de l’analyse de CodeQL a été améliorée grâce à la prise en charge de davantage de bibliothèques et de frameworks dans l’écosystème Python. Par conséquent, CodeQL peut maintenant détecter encore plus de sources potentielles de données utilisateur non approuvées, ainsi que les étapes par lesquelles les données passent et les récepteurs dangereux potentiels où les données peuvent aboutir. Il en résulte une amélioration générale de la qualité des alertes d’code scanning. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

L’analyse du code avec CodeQL comprend maintenant une prise en charge bêta de l’analyse du code dans toutes les versions Ruby courantes, jusqu’à la version 3.02 incluse. Pour plus d’informations, consultez le « journal des modifications de GitHub ».

Plusieurs améliorations ont été apportées à l’API code scanning :

• L’horodatage fixed_at a été ajouté aux alertes. Cet horodatage correspond à la première fois où l’alerte n’a pas été détectée dans une analyse.
• Les résultats de l’alerte peuvent désormais être triés à l’aide de sort et direction sur created, updated ou number. Pour plus d’informations, consultez « Répertorier les alertes d’analyse de code pour un dépôt ».
• Un en-tête Last-Modified a été ajouté à la réponse des alertes et du point de terminaison de l’alerte. Pour plus d’informations, consultez Last-Modified dans la documentation Mozilla.
• Le champ relatedLocations a été ajouté à la réponse de SARIF lorsque vous avez demandé une analyse de l’analyse de code. Le champ peut contenir des emplacements qui ne correspondent pas au premier emplacement de l’alerte. Consultez un exemple dans la spécification SARIF, et pour plus d’informations, consultez « Obtenir une analyse d’analyse du code pour un dépôt ».
• Les données help et tags ont été ajoutées à l’objet des règles d’alerte de réponse de webhook. Pour plus d’informations, consultez « Événements et charges utiles d’alerte d’analyse du code ».
• Les jetons d’accès personnel avec l’étendue public_repo disposent à présent de l’accès en écriture pour les points de terminaison de l’analyse de code sur les dépôts publics, si l’utilisateur dispose de l’autorisation.

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

Les clients GitHub Advanced Security peuvent à présent utiliser l’API REST pour récupérer les résultats de l’analyse des secrets de dépôt privé au niveau de l’entreprise. Le nouveau point de terminaison vient en complément des points de terminaison existants au niveau du dépôt et au niveau de l’organisation. Pour plus d’informations, consultez « Analyse de secrets » dans la documentation de l’API REST.

Le support pour GitHub Mobile n’est actuellement pas activé par défaut pour les nouvelles instances GitHub Enterprise Server. Si vous n’avez pas explicitement désactivé ou activé GitHub Mobile, GitHub Mobile sera activé au moment de la mise à niveau vers GitHub Enterprise Server 3.4.0 ou version ultérieure. Si vous avez auparavant désactivé ou activé GitHub Mobile pour votre instance, votre préférence est maintenue à l’issue de la mise à niveau. Pour plus d’informations, consultez « Gestion de GitHub Mobile pour votre entreprise ».

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

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

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

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

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

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

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

Après avoir enregistré un exécuteur auto-hébergé avec le paramètre --ephemeral à plus d’un niveau (par exemple, entreprise et organisation), l’exécuteur peut rester bloqué dans un état d’inactivité et nécessiter une nouvelle inscription. [Mise à jour : 17/06/2022]

Lors de l’utilisation d’assertions chiffrées SAML avec GitHub Enterprise Server 3.4.0 et 3.4.1, un nouvel attribut XML WantAssertionsEncrypted dans SPSSODescriptor contenait un attribut non valide pour les métadonnées SAML. Les IdP qui utilisent ce point de terminaison de métadonnées SAML peuvent rencontrer des erreurs lors de la validation du schéma XML des métadonnées SAML. Un correctif sera disponible dans la prochaine version du patch. [Mise à jour : 11/04/2022]

Pour contourner ce problème, vous pouvez prendre l’une des deux mesures suivantes.

• Reconfigurez l’IdP en chargeant une copie statique des métadonnées SAML sans l’attribut WantAssertionsEncrypted.
• Copiez les métadonnées SAML, supprimez l’attribut WantAssertionsEncrypted, hébergez-les sur un serveur web et reconfigurez l’IdP pour qu’il pointe vers cette URL.

Dans certains cas, les clients GitHub Advanced Security qui effectuent une mise à niveau vers GitHub Enterprise Server 3.5 ou version ultérieure peuvent remarquer que les alertes de l’analyse secrète sont manquantes dans l’interface utilisateur web et l’API REST. Pour vous assurer que les alertes restent visibles, n’ignorez pas la version 3.4 lorsque vous effectuez une mise à niveau d’une version antérieure vers la version 3.5 ou ultérieure. Un correctif est disponible dans les versions de patch 3.5.5 et 3.6.1.

Pour planifier une mise à niveau via la version 3.4, consultez l’Assistant Mise à niveau. [Mise à jour : 01/09/2022]

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

GitHub Enterprise Server 3.0 a été mis hors service le 16 février 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour bénéficier d’un meilleur niveau de performance, d’une sécurité accrue et de nouvelles fonctionnalités, mettre à niveau vers la version le plus récente de GitHub Enterprise Server dès que possible.

GitHub Enterprise Server 3.1 a été mis hors service le 3 juin 2022. Cela signifie qu’aucune version de patch ne sera publiée, même pour les problèmes de sécurité critiques, après cette date. Pour obtenir de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la version la plus récente de GitHub Enterprise Server dès que possible.

Depuis GitHub Enterprise Server 3.3, GitHub Enterprise Server sur XenServer est déprécié et n’est plus pris en charge. Contactez le support GitHub pour toute question ou préoccupation.

En raison d’une faible utilisation, nous avons déprécié la préversion de l’API Références de contenu dans GitHub Enterprise Server 3.4. L’API était précédemment accessible avec l’en-tête corsair-preview. Les utilisateurs peuvent continuer à accéder à des URL externes sans cette API. Toutes les utilisations enregistrées de l’API Références de contenu ne recevront plus de notification par webhook pour les URL de votre ou vos domaines enregistrés, et nous ne renverrons plus de codes de réponse valides pour les tentatives de mise à jour des attachements de contenu existants.

La préversion de l’API Codes de conduite, qui était accessible avec l’en-tête scarlet-witch-preview, est dépréciée et n’est plus accessible dans GitHub Enterprise Server 3.4. Nous vous recommandons plutôt d’utiliser le point de terminaison « Obtenir les métriques de profil de communauté » pour récupérer des informations sur le code de conduite d’un dépôt. Pour plus d’informations, consultez « Avis de dépréciation : préversion de l’API Codes de conduite » dans le journal des modifications de GitHub.

À compter de GitHub Enterprise Server 3.4, la version dépréciée des points de terminaison d’API d’application OAuth est supprimée. Si vous rencontrez des messages d’erreur 404 sur ces points de terminaison, convertissez votre code dans des versions de l’API d’application OAuth qui n’ont pas access_tokens dans l’URL. Nous avons également désactivé l’utilisation de l’authentification de l’API avec des paramètres de requête. Nous vous recommandons plutôt d’utiliser l’authentification API dans l’en-tête de requête.

L’exécuteur CodeQL est déprécié dans GitHub Enterprise Server 3.4 et n’est plus pris en charge. Cette dépréciation ne concerne que les utilisateurs qui utilisent l’analyse du code de CodeQL dans des systèmes CI/CD tiers, les utilisateurs de GitHub Actions ne sont pas concernés. Nous recommandons vivement aux clients de migrer vers l’interface CLI de CodeQL, qui remplace toutes les fonctionnalités de l’exécuteur CodeQL. Pour plus d’informations, consultez le journal des modifications de GitHub.

À partir de GitHub Enterprise Server 3.1, la prise en charge des extensions de cache binaire propriétaires de GitHub est supprimée progressivement. Ces extensions sont dépréciées dans GitHub Enterprise Server 3.3 et ultérieur.

Tous les dépôts qui étaient déjà présents et actifs sur votre instance GitHub Enterprise Server version 3.1 ou 3.2 ont été automatiquement mis à jour.

Les dépôts qui n’étaient pas présents et actifs avant la mise à niveau vers GitHub Enterprise Server 3.3 peuvent ne pas fonctionner de manière optimale tant qu’une tâche de maintenance du dépôt n’est pas correctement exécutée.

Pour lancer manuellement une tâche de maintenance de dépôt, accédez à https://<hostname>/stafftools/repositories/<owner>/<repository>/network pour chaque dépôt affecté et cliquez sur le bouton Planification.

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 plus d’informations, consultez le journal des modifications de GitHub. [Mise à jour : 14/06/2022]