Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Signature des métadonnées du référentiel dans AL2023

À compter de leur sortie2023.11.20260406, les référentiels AL2023 incluent des signatures cryptographiques pour les métadonnées des référentiels. Le repomd.xml fichier de chaque dépôt est accompagné d'un fichier de signature GPG détaché (repomd.xml.asc) que vous pouvez utiliser pour vérifier l'authenticité et l'intégrité des métadonnées du référentiel avant le téléchargement des packages.

Cette signature s'ajoute à la signature de package RPM existante (gpgcheck), qui vérifie les packages individuels. La signature des métadonnées du référentiel vérifie les métadonnées qui décrivent le contenu du référentiel, telles que la liste des packages disponibles et leurs checksums.

La signature des packages protège chaque package. L'index de métadonnées qui répertorie ces packages est par ailleurs fiable uniquement sur la base du TLS et des checksums. Sans signature sur l'index, un miroir ou un chemin de transport compromis peut diffuser des métadonnées modifiées qui masquent ou bloquent les mises à jour de sécurité. La signature des métadonnées du référentiel comble cette lacune et ne dépend pas de la confiance en matière de miroir ou de transport.

Fonctionnement de la signature des métadonnées du référentiel

Lorsque les référentiels AL2023 sont publiés, les métadonnées du référentiel (repomd.xml) sont signées à l'aide d'une AWS clé KMS. La signature détachée (repomd.xml.asc) qui en résulte est placée à côté des métadonnées dans le référentiel.

Lorsque vous l'activez repo_gpgcheck dans la configuration de votre référentiel, DNF vérifie la repomd.xml.asc signature par rapport à la clé publique GPG avant d'utiliser les métadonnées du référentiel. Si la vérification échoue, DNF rejette les métadonnées et n'exécute aucune opération de package à partir de ce référentiel.

La première fois DNF que vous vérifiez les métadonnées d'un dépôt, vous êtes invité à importer la clé de signature de ce référentiel dans un jeu de clés par référentiel. La valeur par défaut de cette invite est. No Si vous le refusez, le dépôt DNF est ignoré. Pour plus d'informations à ce sujetrepo_gpgcheck, consultez la référence DNF de configuration.

Il s'agit de la même clé déjà utilisée pour la vérification des packages, mais elle est DNF stockée dans un jeu de clés distinct pour les vérifications de métadonnées. Vous êtes invité à le confirmer même si la clé se trouve déjà sur le disque. Il s'agit d'DNFun comportement attendu.

Les référentiels AL2023 suivants incluent des métadonnées signées :

Différence entre gpgcheck et repo_gpgcheck

Nous vous recommandons d'activer gpgcheck les deuxrepo_gpgcheck, une fois que vous aurez confirmé que votre automatisation est prête. Cela permet de vérifier à la fois les métadonnées du référentiel et les packages individuels avant utilisation. Avant de procéder à l'activationrepo_gpgcheck, consultezUtiliser la vérification des métadonnées du référentiel dans le cadre de l'automatisation.

Activation de la vérification des métadonnées du référentiel

Vous pouvez activer la vérification des métadonnées des référentiels individuels en mettant à jour leurs fichiers de configuration.

Activer pour un référentiel spécifique

Les fichiers de configuration du référentiel AL2023 sont /etc/yum.repos.d/ définis repo_gpgcheck=0 par défaut. Pour activer la vérification des métadonnées du référentiel, remplacez cette valeur par celle 1 indiquée dans la configuration du référentiel. Par exemple, pour l'activer pour le référentiel principal :

[amazonlinux]
name=Amazon Linux 2023 repository
...
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023

Désactiver la vérification des métadonnées du référentiel

Pour revenir au comportement précédent, définissez-le repo_gpgcheck=0 dans le fichier de configuration du référentiel. La prochaine actualisation des métadonnées aboutit sans vérification.

[ec2-user ~]$ sudo sed -i 's/^repo_gpgcheck=1/repo_gpgcheck=0/' /etc/yum.repos.d/amazonlinux.repo
[ec2-user ~]$ sudo dnf -y makecache

Vérifier que la signature des métadonnées du référentiel fonctionne

Après l'activationrepo_gpgcheck=1, vous pouvez vérifier que la vérification des métadonnées fonctionne en vidant le DNF cache et en actualisant les métadonnées :

[ec2-user ~]$ sudo dnf clean metadata
[ec2-user ~]$ sudo dnf makecache

La première fois DNF que les métadonnées d'un dépôt sont vérifiées, il vous est demandé d'importer la clé de signature de ce dépôt. Saisissez y pour confirmer. Une fois la clé importée, DNF crée le cache de métadonnées sans erreur. Vous verrez des résultats similaires à ce qui suit :

Amazon Linux 2023 repository                    1.7 MB/s | 1.8 kB     00:00
Importing GPG key 0xD832C631:
 Userid     : "Amazon Linux <amazon-linux@amazon.com>"
 Fingerprint: B21C 50FA 44A9 9720 EAA7 2F7F E951 904A D832 C631
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023
Is this ok [y/N]: y
Amazon Linux 2023 repository                      18 MB/s |  55 MB     00:03
Metadata cache created.

La valeur par défaut de l'invite d'importation est. No Si vous le refusez, le référentiel DNF et les rapports sont ignorés Ignoring repositories dans la sortie. Si la vérification échoue, DNF signale une erreur de signature GPG et ne crée pas le cache.

Pour les courses sans surveillance, voirUtiliser la vérification des métadonnées du référentiel dans le cadre de l'automatisation.

Utiliser la vérification des métadonnées du référentiel dans le cadre de l'automatisation

Pour éviter cela, transmettez l'-yoption à toutes les DNF commandes sans surveillance qui actualisent les métadonnées, y compris les tâches d'intégration continue, les builds d'images et de conteneurscloud-init, la gestion des configurations et les tâches cron.

[ec2-user ~]$ sudo dnf -y makecache
[ec2-user ~]$ sudo dnf -y check-update
[ec2-user ~]$ sudo dnf -y upgrade

Les commandes qui actualisent les métadonnées ont besoin de-y. Les commandes qui lisent uniquement le cache local ou la base de données RPM locale, ou qui utilisent cette -C option, n'actualisent pas les métadonnées et n'affichent aucune invite. Pour obtenir la liste complète, consultez Commandes qui actualisent les métadonnées du référentiel.

Conservez -y votre automatisation en permanence. La clé est importée une fois par URL de dépôt, et non une fois par hôte. L'AL2023 crée chaque URL de référentiel à partir de la version verrouillée (releasever) et de la AWS région, de sorte qu'une mise à niveau de version du système d'exploitation ou un changement de région aboutit à une nouvelle URL et affiche une nouvelle invite. La clé de signature ne change pas ; seul l'emplacement de son trousseau change. Ne pré-ensemencez pas ou ne précuisez pas la clé comme solution ponctuelle, car la prochaine mise à niveau de version ou la prochaine région utilisera un nouveau trousseau de clés et vous le demandera à nouveau.

L'exécution dnf clean all efface les métadonnées mises en cache mais ne supprime pas la clé importée dans la même version. Cela ne déclenche pas à nouveau l'invite.

Les constructions d'images de conteneurs nécessitent une attention particulière. Chaque RUN dnf étape de la création d'une image se fait sans surveillance, et le trousseau de clés fait partie du système de fichiers image. Il démarre donc vide à chaque nouvelle image. L'invite apparaît pendant la compilation, indépendamment de ce que vos hôtes actifs ont déjà importé. Transmettez -y les builds d'images.

Commandes qui actualisent les métadonnées du référentiel

Toute commande qui télécharge ou actualise les métadonnées du référentiel déclenche l'importation de la clé et l'invite. Les commandes qui lisent uniquement le cache local ou la base de données RPM locale ne le font pas. Les options modifient le résultat : par exemple, -v rendent le repolist fetch, le --installed conserve list et le info local, -C ou --cacheonly évitent l'extraction et --refresh la forcent. En cas de doute, passez-y.

Un dépôt ignoré de cette façon est indiqué Ignoring repositories dans la sortie, mais la plupart de ces commandes se terminent toujours avec le statut 0 car skip_if_unavailable=True AL2023 est défini. Ne vous fiez pas uniquement au code de sortie. Passez -y pour que l'importation de la clé réussisse.

Détecter un dépôt ignoré

Le code de sortie à lui seul ne confirme pas la réussite de la vérification. Un dépôt ignoré se ferme et la clé de signature est conservée une fois qu'une exécution l'importe. Une vérification ultérieure peut donc réussir alors qu'une étape précédente échoue toujours. 0 Utilisez plutôt ces deux vérifications :

[ec2-user ~]$ sudo dnf makecache 2>&1 | grep -q "Ignoring repositories" && { echo "repo skipped"; exit 1; }

Versions épinglées

Si vous épinglez releasever (avec --releasever/etc/dnf/vars/releasever, oudnf.conf) à une version publiée auparavant2023.11.20260406, cette version ne contient aucun fichier de signature et repo_gpgcheck=1 ne parvient pas à actualiser le référentiel :

Error: Failed to download metadata for repo 'amazonlinux':
GPG verification is enabled, but GPG signature is not available...

Une version épinglée ne reçoit aucune mise à jour au-delà de cette version. Si vous épinglez, épinglez à la version 2023.11.20260406 ou à une version ultérieure, ou à un ensemblerepo_gpgcheck=0.

Clés publiques GPG pour les référentiels AL2023

Les clés publiques GPG utilisées pour la vérification des métadonnées du référentiel sont installées par les RPM de configuration du référentiel correspondants. /etc/pki/rpm-gpg/ Le tableau suivant répertorie les clés publiques utilisées par chaque référentiel.

Ces clés sont automatiquement installées lorsque vous installez le RPM de configuration du référentiel correspondant.