Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Firma dei metadati del repository in AL2023
A partire dal rilascio`2023.11.20260406`, i repository AL2023 includono firme crittografiche per i metadati del repository. Ogni file del repository è accompagnato da un `repomd.xml` file di firma GPG separato (`repomd.xml.asc`) che è possibile utilizzare per verificare l'autenticità e l'integrità dei metadati del repository prima del download dei pacchetti.
Questa firma si aggiunge alla firma del pacchetto RPM esistente ()`gpgcheck`, che verifica i singoli pacchetti. La firma dei metadati del repository verifica i metadati che descrivono il contenuto del repository, come l'elenco dei pacchetti disponibili e i relativi checksum.
La firma dei pacchetti protegge ogni pacchetto. L'indice dei metadati che elenca tali pacchetti è altrimenti affidabile solo in base a TLS e checksum. Senza una firma sull'indice, un mirror o un percorso di trasporto compromesso potrebbe fornire metadati modificati che nascondono o bloccano gli aggiornamenti di sicurezza. La firma dei metadati del repository colma questa lacuna e non dipende dall'affidabilità del mirror o del trasporto.
## Come funziona la firma dei metadati nei repository
Quando i repository AL2023 vengono pubblicati, i metadati del repository (`repomd.xml`) vengono firmati utilizzando una chiave KMS.AWS La firma distaccata risultante (`repomd.xml.asc`) viene posizionata accanto ai metadati nel repository.
Quando la abiliti `repo_gpgcheck` nella configurazione del repository, DNF verifica la `repomd.xml.asc` firma rispetto alla chiave pubblica GPG prima di utilizzare i metadati del repository. Se la verifica fallisce, DNF rifiuta i metadati e non esegue le operazioni sui pacchetti da quel repository.
La prima volta che DNF verifica i metadati di un repository, viene richiesto all'utente di importare la chiave di firma del repository in un portachiavi specifico per repository. L'impostazione predefinita di questo prompt è. `No` Se lo rifiuti, DNF salta il repository. Per ulteriori informazioni in merito`repo_gpgcheck`, consulta il [DNFConfiguration](https://dnf.readthedocs.io/en/latest/conf_ref.html) Reference.
Si tratta della stessa chiave già utilizzata per la verifica dei pacchetti, ma la DNF memorizza in un portachiavi separato per il controllo dei metadati. Ti viene richiesto di confermarla anche se la chiave è già presente su disco. Si tratta di un DNF comportamento previsto.
I seguenti repository AL2023 includono metadati firmati:
+ Archivio principale () `amazonlinux`
+ Archivio Kernel Livepatch () `kernel-livepatch`
+ Archivio NVIDIA () `amazonlinux-nvidia`
+ Pacchetti supplementari per il repository Amazon Linux () `amazonlinux-spal`
## `Differenza tra gpgcheck e repo_gpgcheck`
| Impostazione | Cosa verifica | Impostazione predefinita in AL2023 |
| --- | --- | --- |
| gpgcheck=1 | Verifica la firma GPG dei singoli pacchetti RPM prima dell'installazione. | Abilitato |
| repo\_gpgcheck=1 | Verifica la firma GPG dei metadati del repository () prima di utilizzare il repository. repomd.xml | Disabilitato per impostazione predefinita. |
Ti consigliamo di abilitare entrambi `gpgcheck` e`repo_gpgcheck`, dopo aver confermato che l'automazione è pronta. Ciò verifica sia i metadati del repository che i singoli pacchetti prima dell'uso. Prima di abilitarlo, consulta. `repo_gpgcheck` [Utilizza la verifica dei metadati del repository nell'automazione](#repo-metadata-signing-automation)
## Attivazione della verifica dei metadati del repository
È possibile abilitare la verifica dei metadati del repository per i singoli repository aggiornando i relativi file di configurazione.
**Importante**
La verifica della firma dei metadati del repository non è abilitata per impostazione predefinita. Rimane disattivata finché non viene modificata. Prima di abilitarlo, verifica che ogni DNF comando automatico dell'automazione superi l'`-y`opzione. Per ulteriori informazioni, consulta [Utilizza la verifica dei metadati del repository nell'automazione](#repo-metadata-signing-automation).
### Abilita per un repository specifico
I file di configurazione del repository AL2023 sono `/etc/yum.repos.d/` `repo_gpgcheck=0` impostati di default. Per abilitare la verifica dei metadati del repository, modifica questo valore `1` in nella configurazione del repository. Ad esempio, per abilitarlo per il repository principale:
```
[amazonlinux]
name=Amazon Linux 2023 repository
...
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023
```
### Disattiva la verifica dei metadati del repository
Per tornare al comportamento precedente, impostalo `repo_gpgcheck=0` nel file di configurazione del repository. Il successivo aggiornamento dei metadati viene eseguito senza verifica.
```
[ec2-user ~]$ sudo sed -i 's/^repo_gpgcheck=1/repo_gpgcheck=0/' /etc/yum.repos.d/amazonlinux.repo
[ec2-user ~]$ sudo dnf -y makecache
```
## Verifica del corretto funzionamento della firma dei metadati del repository
Dopo l'attivazione`repo_gpgcheck=1`, puoi verificare che la verifica dei metadati funzioni svuotando la DNF cache e aggiornando i metadati:
```
[ec2-user ~]$ sudo dnf clean metadata
[ec2-user ~]$ sudo dnf makecache
```
La prima volta che DNF verifica i metadati di un repository, ti chiede di importare la chiave di firma di quel repository. Immettere `y` per confermare. Dopo l'importazione della chiave, DNF crea la cache dei metadati senza errori. Verrà visualizzato un output simile al seguente:
```
Amazon Linux 2023 repository 1.7 MB/s | 1.8 kB 00:00
Importing GPG key 0xD832C631:
Userid : "Amazon Linux "
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.
```
L'impostazione predefinita del prompt di importazione è. `No` Se lo rifiuti, DNF salta il repository e riporta i report nell'output. `Ignoring repositories` Se la verifica fallisce, DNF segnala un errore di firma GPG e non crea la cache.
Per le corse non presidiate, vedere. [Utilizza la verifica dei metadati del repository nell'automazione](#repo-metadata-signing-automation)
## Utilizza la verifica dei metadati del repository nell'automazione
**Nota**
L'impostazione predefinita del prompt di importazione delle chiavi è. `No` Un'DNFesecuzione automatica non può rispondere alla richiesta, quindi rifiuta l'importazione e salta il repository. Poiché AL2023 viene impostato`skip_if_unavailable=True`, il comando termina comunque con lo status. `0` Di conseguenza, l'automazione segnala l'esito positivo mentre l'host non riceve pacchetti o aggiornamenti. Il segno di ciò è `Ignoring repositories` nell'output.
Per evitare che ciò accada, passa l'`-y`opzione a ogni DNF comando automatico che aggiorna i metadati, inclusi i processi di integrazione continua, le build di immagini e contenitori, `cloud-init` la gestione della configurazione e i cron job.
```
[ec2-user ~]$ sudo dnf -y makecache
[ec2-user ~]$ sudo dnf -y check-update
[ec2-user ~]$ sudo dnf -y upgrade
```
Sono necessari i comandi che aggiornano i metadati. `-y` I comandi che leggono solo la cache locale o il database RPM locale o che utilizzano l'`-C`opzione non aggiornano i metadati e non richiedono alcuna richiesta. Per l'elenco completo, consulta [Comandi che aggiornano i metadati del repository](#repo-metadata-signing-command-reference).
Mantieni la tua automazione `-y` in modo permanente. La chiave viene importata una volta per URL del repository, non una volta per host. AL2023 crea ogni URL del repository dalla versione bloccata (`releasever`) e dalla AWS regione, quindi un aggiornamento della versione del sistema operativo o una modifica della regione si risolvono in un nuovo URL e vengono nuovamente richiesti. La chiave di firma non cambia, cambia solo la posizione del portachiavi. Non preimpostate o preimpostate la chiave come soluzione una tantum, perché il prossimo aggiornamento della versione o della regione utilizzerà un nuovo portachiavi e le relative istruzioni.
L'esecuzione `dnf clean all` cancella i metadati memorizzati nella cache ma non rimuove la chiave importata all'interno della stessa versione. Non riattiva il prompt.
Le build di immagini dei contenitori richiedono un'attenzione particolare. Ogni `RUN dnf` fase della creazione di un'immagine è automatica e il portachiavi fa parte del file system di immagini, quindi inizia vuoto in ogni nuova immagine. Il prompt viene visualizzato durante la compilazione indipendentemente da ciò che gli host in esecuzione hanno già importato. Passa `-y` le build di immagini.
**Nota**
Se si guida DNF come libreria Python (`import dnf`), il prompt non si applica. La libreria importa la chiave senza chiedere conferma, quindi i metadati vengono caricati senza. `-y`
## Comandi che aggiornano i metadati del repository
Qualsiasi comando che scarica o aggiorna i metadati del repository attiva l'importazione della chiave e il prompt. I comandi che leggono solo la cache locale o il database RPM locale non lo fanno. Le opzioni modificano il risultato: ad esempio, `-v` rende `repolist` fetch, `--installed` keep `list` e `info` local `-C` oppure `--cacheonly` evita il recupero e lo forza. `--refresh` In caso di dubbio, passa. `-y`
| Comando | Aggiorna i metadati |
| --- | --- |
| dnf makecache | Sì |
| dnf check-update | Sì |
| dnf upgrade, dnf update | Sì |
| dnf upgrade-minimal | Sì |
| dnf distro-sync | Sì |
| dnf install | Sì |
| dnf reinstall | Sì |
| dnf downgrade | Sì |
| dnf autoremove | Sì |
| dnf swap | Sì |
| dnf list(impostazione predefinita o) --available | Sì |
| dnf info(impostazione predefinita o--available) | Sì |
| dnf search | Sì |
| dnf provides | Sì |
| dnf repoquery | Sì |
| dnf repoinfo | Sì |
| dnf deplist | Sì |
| dnf repository-packages | Sì |
| dnf updateinfo | Sì |
| dnf group(elenco, informazioni, installazione) | Sì |
| dnf module(elenco, informazioni) | Sì |
| dnf shell(se i suoi sottocomandi vengono recuperati) | Sì |
| dnf builddep | Sì |
| dnf changelog | Sì |
| dnf debuginfo-install | Sì |
| dnf download | Sì |
| dnf repoclosure | Sì |
| dnf repograph | Sì |
| dnf reposync | Sì |
| dnf debug-dump | Sì |
| dnf repolist -v(prolisso) | Sì |
| dnf repolist(semplice o--all) | No |
| dnf list --installed, dnf info --installed | No |
| dnf remove, dnf erase | No |
| dnf mark | No |
| dnf history | No |
| dnf check | No |
| dnf clean | No |
| dnf config-manager | No |
| dnf needs-restarting | No |
| dnf alias | No |
| dnf help | No |
| dnf repomanage | No |
| dnf repodiff | No (errori a meno che non vengano denominati due repository) |
| dnf copr | No |
| dnf groups-manager | No |
| dnf playground | No |
| dnf debug-restore | No (agisce su un dump salvato) |
| Qualsiasi comando con -C o --cacheonly | No |
Un repository ignorato in questo modo viene riportato come `Ignoring repositories` nell'output, ma la maggior parte di questi comandi termina comunque con status perché `0` AL2023 viene impostato. `skip_if_unavailable=True` Non fate affidamento solo sul codice di uscita. Passa `-y` in modo che l'importazione della chiave abbia successo.
## Rileva un repository ignorato
Il codice di uscita da solo non conferma che la verifica sia riuscita. Un repository ignorato viene chiuso e la `0` chiave di firma persiste anche dopo l'importazione da parte di qualsiasi esecuzione, quindi un controllo successivo può avere esito positivo mentre il passaggio precedente non riesce ancora. Utilizzate invece questi due controlli:
+ Controlla la tua automazione. Verifica che ogni comando di recupero dei metadati DNF venga eseguito. `-y` Questo è ciò che ti consente di lavorare sul prossimo nuovo URL del repository.
+ Controlla l'output di`Ignoring repositories`. Il comando seguente ha esito negativo quando il repository viene ignorato, ed è possibile utilizzarlo per fallire una pipeline:
```
[ec2-user ~]$ sudo dnf makecache 2>&1 | grep -q "Ignoring repositories" && { echo "repo skipped"; exit 1; }
```
## Versioni bloccate
Se si aggiunge `releasever` (con `--releasever` o`dnf.conf`) a una versione rilasciata in precedenza`2023.11.20260406`, tale versione non ha un file di firma e `repo_gpgcheck=1` non riesce ad aggiornare il repository: `/etc/dnf/vars/releasever`
```
Error: Failed to download metadata for repo 'amazonlinux':
GPG verification is enabled, but GPG signature is not available...
```
Una versione bloccata non riceve aggiornamenti oltre a quella versione. Se si aggiunge, si aggiunge alla versione `2023.11.20260406` o successiva oppure si imposta`repo_gpgcheck=0`.
## Chiavi pubbliche GPG per i repository AL2023
Le chiavi pubbliche GPG utilizzate per la verifica dei metadati del repository vengono installate dai corrispondenti RPM di configurazione del repository su. `/etc/pki/rpm-gpg/` La tabella seguente elenca le chiavi pubbliche utilizzate da ciascun repository.
| Repository | Chiave di firma del pacchetto | Chiave di firma Repodata | Distribuito in |
| --- | --- | --- | --- |
| Nucleo (amazonlinux) | RPM-GPG-KEY-amazon-linux-2023 | RPM-GPG-KEY-amazon-linux-2023 | system-release |
| Kernel Livepatch () kernel-livepatch | RPM-GPG-KEY-amazon-linux-2023 | RPM-GPG-KEY-amazon-linux-2023 | system-release |
| NVIDIA () amazonlinux-nvidia | RPM-GPG-KEY-NVIDIA-D42D0685 | RPM-GPG-KEY-amazon-linux-2023-nvidia | nvidia-release |
| SPAL () amazonlinux-spal | RPM-GPG-KEY-amazonlinux-spal | RPM-GPG-KEY-amazonlinux-spal | spal-release |
Queste chiavi vengono installate automaticamente quando si installa l'RPM di configurazione del repository corrispondente.