As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Assinatura de metadados do repositório no AL2023
A partir do lançamento`2023.11.20260406`, os repositórios AL2023 incluem assinaturas criptográficas para metadados do repositório. Cada `repomd.xml` arquivo do repositório é acompanhado por um arquivo de assinatura GPG separado (`repomd.xml.asc`) que você pode usar para verificar a autenticidade e a integridade dos metadados do repositório antes que os pacotes sejam baixados.
Essa assinatura é adicional à assinatura do pacote RPM existente (`gpgcheck`), que verifica pacotes individuais. A assinatura de metadados do repositório verifica os metadados que descrevem o conteúdo do repositório, como a lista de pacotes disponíveis e suas somas de verificação.
A assinatura de pacotes protege cada pacote. Caso contrário, o índice de metadados que lista esses pacotes é confiável com base apenas em TLS e somas de verificação. Sem uma assinatura no índice, um espelho ou caminho de transporte comprometido pode fornecer metadados modificados que ocultam ou bloqueiam atualizações de segurança. A assinatura de metadados do repositório preenche essa lacuna e não depende da confiabilidade do espelho ou do transporte.
## Como funciona a assinatura de metadados do repositório
Quando os repositórios AL2023 são publicados, os metadados do repositório (`repomd.xml`) são assinados usando uma chave KMS.AWS A assinatura separada resultante (`repomd.xml.asc`) é colocada ao lado dos metadados no repositório.
Quando você habilita `repo_gpgcheck` na configuração do seu repositório, DNF verifica a `repomd.xml.asc` assinatura em relação à chave pública GPG antes de usar os metadados do repositório. Se a verificação falhar, DNF rejeita os metadados e não executa operações de pacote a partir desse repositório.
Na primeira vez que DNF verifica os metadados de um repositório, ele solicita que você importe a chave de assinatura desse repositório em um chaveiro por repositório. Esse prompt é padronizado como. `No` Se você recusar, DNF pulará o repositório. Para obter mais informações sobre`repo_gpgcheck`, consulte a [Referência DNF de configuração](https://dnf.readthedocs.io/en/latest/conf_ref.html).
Essa é a mesma chave já usada para verificação de pacotes, mas a DNF armazena em um chaveiro separado para verificações de metadados. Você será solicitado a confirmá-la, mesmo que a chave já esteja no disco. Esse é o DNF comportamento esperado.
Os seguintes repositórios do AL2023 incluem metadados assinados:
+ Repositório principal () `amazonlinux`
+ Repositório Kernel Livepatch () `kernel-livepatch`
+ Repositório NVIDIA () `amazonlinux-nvidia`
+ Pacotes suplementares para o repositório Amazon Linux () `amazonlinux-spal`
## `Diferença entre gpgcheck e repo_gpgcheck`
| Configuração | O que ele verifica | Padrão em AL2023 |
| --- | --- | --- |
| gpgcheck=1 | Verifica a assinatura GPG de pacotes RPM individuais antes da instalação. | Habilitado |
| repo\_gpgcheck=1 | Verifica a assinatura GPG dos metadados do repositório (repomd.xml) antes de usar o repositório. | Desabilitado por padrão. |
Recomendamos que você habilite os dois `gpgcheck` e`repo_gpgcheck`, depois de confirmar que sua automação está pronta. Isso verifica os metadados do repositório e os pacotes individuais antes do uso. Antes de habilitar`repo_gpgcheck`, consulte[Use a verificação de metadados do repositório na automação](#repo-metadata-signing-automation).
## Habilitando a verificação de metadados do repositório
Você pode habilitar a verificação de metadados do repositório para repositórios individuais atualizando seus arquivos de configuração.
**Importante**
A verificação da assinatura de metadados do repositório não está habilitada por padrão. Ele permanece desativado até que você o altere. Antes de habilitá-lo, confirme se cada DNF comando autônomo em sua automação passa pela `-y` opção. Para obter mais informações, consulte [Use a verificação de metadados do repositório na automação](#repo-metadata-signing-automation).
### Habilitar para um repositório específico
Os arquivos de configuração do repositório AL2023 são `/etc/yum.repos.d/` definidos `repo_gpgcheck=0` por padrão. Para habilitar a verificação de metadados do repositório, altere esse valor para `1` na configuração do repositório. Por exemplo, para habilitá-lo para o repositório principal:
```
[amazonlinux]
name=Amazon Linux 2023 repository
...
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023
```
### Desativar a verificação de metadados do repositório
Para retornar ao comportamento anterior, defina `repo_gpgcheck=0` no arquivo de configuração do repositório. A próxima atualização de metadados é bem-sucedida sem verificação.
```
[ec2-user ~]$ sudo sed -i 's/^repo_gpgcheck=1/repo_gpgcheck=0/' /etc/yum.repos.d/amazonlinux.repo
[ec2-user ~]$ sudo dnf -y makecache
```
## Verificando se a assinatura de metadados do repositório está funcionando
Depois de habilitar`repo_gpgcheck=1`, você pode verificar se a verificação de metadados está funcionando limpando o DNF cache e atualizando os metadados:
```
[ec2-user ~]$ sudo dnf clean metadata
[ec2-user ~]$ sudo dnf makecache
```
A primeira vez que DNF verifica os metadados de um repositório, ele solicita que você importe a chave de assinatura desse repositório. Digite `y` para confirmar. Depois que a chave é importada, DNF cria o cache de metadados sem erros. Você verá uma saída semelhante à seguinte:
```
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.
```
O prompt de importação é padronizado como. `No` Se você recusar, DNF ignora o repositório e os relatórios `Ignoring repositories` na saída. Se a verificação falhar, DNF reporta um erro de assinatura GPG e não cria o cache.
Para corridas autônomas, consulte[Use a verificação de metadados do repositório na automação](#repo-metadata-signing-automation).
## Use a verificação de metadados do repositório na automação
**nota**
O prompt de importação de chaves é padronizado como. `No` Uma DNF execução autônoma não pode responder à solicitação, então ela recusa a importação e ignora o repositório. Como o AL2023 é definido`skip_if_unavailable=True`, o comando ainda sai com status. `0` Como resultado, a automação relata o sucesso enquanto o host não recebe pacotes ou atualizações. O sinal disso está `Ignoring repositories` na saída.
Para evitar isso, passe a `-y` opção para cada DNF comando autônomo que atualiza os metadados, incluindo trabalhos de integração contínua, compilações de imagens e contêineres`cloud-init`, gerenciamento de configuração e tarefas cron.
```
[ec2-user ~]$ sudo dnf -y makecache
[ec2-user ~]$ sudo dnf -y check-update
[ec2-user ~]$ sudo dnf -y upgrade
```
Comandos que atualizam os metadados necessários. `-y` Os comandos que leem somente o cache local ou o banco de dados RPM local, ou que usam a `-C` opção, não atualizam os metadados e não solicitam. Para ver a lista completa, consulte [Comandos que atualizam os metadados do repositório](#repo-metadata-signing-command-reference).
Mantenha `-y` sua automação permanentemente. A chave é importada uma vez por URL do repositório, não uma vez por host. O AL2023 cria cada URL do repositório a partir da versão bloqueada (`releasever`) e da AWS Região, portanto, uma atualização da versão do sistema operacional ou uma alteração de região é resolvida para uma nova URL e é solicitada novamente. A chave de assinatura não muda; somente a localização do chaveiro muda. Não pré-semeie nem pré-prepare a chave como uma correção única, porque a próxima atualização de versão ou região usa um novo chaveiro e avisa novamente.
A execução `dnf clean all` limpa os metadados em cache, mas não remove a chave importada na mesma versão. Ele não aciona novamente o prompt.
As construções de imagens de contêineres precisam de atenção especial. Cada `RUN dnf` etapa na construção de uma imagem é autônoma, e o chaveiro faz parte do sistema de arquivos de imagem, então ele começa vazio em cada imagem nova. O prompt aparece durante a compilação, independentemente do que seus hosts em execução já tenham importado. Passe `-y` as construções de imagens.
**nota**
Se você dirige DNF como uma biblioteca Python (`import dnf`), o prompt não se aplica. A biblioteca importa a chave sem aviso prévio, então os metadados são carregados sem ela. `-y`
## Comandos que atualizam os metadados do repositório
Qualquer comando que baixe ou atualize os metadados do repositório aciona a importação da chave e o prompt. Os comandos que leem somente o cache local ou o banco de dados RPM local não o fazem. As opções alteram o resultado: por exemplo, `-v` torna a `repolist` busca, `--installed` mantém `list` e `info` local, `-C` ou `--cacheonly` evita a busca e `--refresh` a força. Em caso de dúvida, passe`-y`.
| Command | Atualiza os metadados |
| --- | --- |
| dnf makecache | Sim |
| dnf check-update | Sim |
| dnf upgrade, dnf update | Sim |
| dnf upgrade-minimal | Sim |
| dnf distro-sync | Sim |
| dnf install | Sim |
| dnf reinstall | Sim |
| dnf downgrade | Sim |
| dnf autoremove | Sim |
| dnf swap | Sim |
| dnf list(padrão ou--available) | Sim |
| dnf info(padrão ou--available) | Sim |
| dnf search | Sim |
| dnf provides | Sim |
| dnf repoquery | Sim |
| dnf repoinfo | Sim |
| dnf deplist | Sim |
| dnf repository-packages | Sim |
| dnf updateinfo | Sim |
| dnf group(lista, informações, instalação) | Sim |
| dnf module(lista, informações) | Sim |
| dnf shell(se seus subcomandos forem buscados) | Sim |
| dnf builddep | Sim |
| dnf changelog | Sim |
| dnf debuginfo-install | Sim |
| dnf download | Sim |
| dnf repoclosure | Sim |
| dnf repograph | Sim |
| dnf reposync | Sim |
| dnf debug-dump | Sim |
| dnf repolist -v(detalhado) | Sim |
| dnf repolist(simples ou--all) | Não |
| dnf list --installed, dnf info --installed | Não |
| dnf remove, dnf erase | Não |
| dnf mark | Não |
| dnf history | Não |
| dnf check | Não |
| dnf clean | Não |
| dnf config-manager | Não |
| dnf needs-restarting | Não |
| dnf alias | Não |
| dnf help | Não |
| dnf repomanage | Não |
| dnf repodiff | Não (erros, a menos que dois repositórios sejam nomeados) |
| dnf copr | Não |
| dnf groups-manager | Não |
| dnf playground | Não |
| dnf debug-restore | Não (atua em um despejo salvo) |
| Qualquer comando com -C ou --cacheonly | Não |
Um repositório ignorado dessa forma é relatado como `Ignoring repositories` na saída, mas a maioria desses comandos ainda sai com status porque `0` AL2023 é definido. `skip_if_unavailable=True` Não confie apenas no código de saída. Passe `-y` para que a importação da chave seja bem-sucedida.
## Detectar um repositório ignorado
O código de saída por si só não confirma que a verificação foi bem-sucedida. Um repositório ignorado é `0` encerrado e a chave de assinatura persiste quando qualquer execução é importada, portanto, uma verificação posterior pode ser aprovada enquanto uma etapa anterior ainda falha. Em vez disso, use essas duas verificações:
+ Audite sua automação. Confirme se todos os comandos de busca de metadados DNF são aprovados. `-y` É isso que mantém você trabalhando na próxima nova URL do repositório.
+ Verifique a saída para`Ignoring repositories`. O comando a seguir falha quando o repositório é ignorado, o que você pode usar para falhar em um pipeline:
```
[ec2-user ~]$ sudo dnf makecache 2>&1 | grep -q "Ignoring repositories" && { echo "repo skipped"; exit 1; }
```
## Versões fixadas
Se você fixar `releasever` (com `--releasever``/etc/dnf/vars/releasever`, ou`dnf.conf`) em uma versão lançada anteriormente`2023.11.20260406`, essa versão não terá arquivo de assinatura e `repo_gpgcheck=1` falhará ao atualizar o repositório:
```
Error: Failed to download metadata for repo 'amazonlinux':
GPG verification is enabled, but GPG signature is not available...
```
Uma versão fixada não recebe atualizações além dessa versão. Se você fixar, fixe na versão `2023.11.20260406` ou posterior, ou defina`repo_gpgcheck=0`.
## Chaves públicas GPG para repositórios AL2023
As chaves públicas GPG usadas para verificação de metadados do repositório são instaladas pelos RPMs de configuração do repositório correspondentes em. `/etc/pki/rpm-gpg/` A tabela a seguir lista as chaves públicas usadas por cada repositório.
| Repositório | Chave de assinatura do pacote | Chave de assinatura Repodata | Distribuído em |
| --- | --- | --- | --- |
| Núcleo (amazonlinux) | RPM-GPG-KEY-amazon-linux-2023 | RPM-GPG-KEY-amazon-linux-2023 | system-release |
| Livepatch do Kernel () 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 |
Essas chaves são instaladas automaticamente quando você instala o RPM de configuração do repositório correspondente.