[PATCH v2 0/5] docs: pt_BR: Complete PGP maintainer guide translation

[PATCH v2 0/5] docs: pt_BR: Complete PGP maintainer guide translation

[Daniel Pereira]

This series provides the complete Brazilian Portuguese translation for
the Kernel Maintainer PGP guide. The translation was divided into 
subsequent patches to facilitate review, covering PGP basics, hardware
tokens (smartcards), Git integration, and identity verification.

All internal cross-references were updated to ensure a clean Sphinx 
build, and terminology aligns with the existing pt_BR documentation.

Changes in v2:
- Fixed translation of "Periodic release snapshots" to "Arquivos 
  tarballs por release" as suggested by Mauro Carvalho Chehab.
- Corrected a double-hyphen formatting error in the first translation 
  patch.
- Added missing Signed-off-by and fixed line wrapping in the 
  KVM index patch (1/5).
- Rebased onto the latest docs-next branch.

Daniel Pereira (5):
  docs: add maintainer-kvm-x86 to maintainer-handbooks index
  docs: pt_BR: start translation of the PGP maintainer guide
  docs: pt_BR: continue PGP guide translation
  docs: pt_BR: continue PGP guide: Git and maintenance
  docs: pt_BR: complete PGP guide translation

[PATCH v2 1/5] docs: add maintainer-kvm-x86 to maintainer-handbooks index

[Daniel Pereira]

Include the KVM x86 subsystem development process notes to the main
documentation tree. This ensures the new maintainer guide is properly
indexed and reachable.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/maintainer-handbooks.rst          | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
index ba36df8ee..bf7a38147 100644
--- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
@@ -16,3 +16,4 @@ Conteúdos:
    maintainer-netdev
    maintainer-soc
    maintainer-soc-clean-dts
+   maintainer-kvm-x86
-- 
2.47.3

[PATCH v2 2/5] docs: pt_BR: start translation of the PGP maintainer guide

[Daniel Pereira]

Translate the initial sections of the Kernel Maintainer PGP guide
into Brazilian Portuguese.

This first part covers:
- The role of PGP in Linux kernel development.
- The principle of trusting developers instead of infrastructure.
- GnuPG tool requirements and gpg-agent configuration.
- Understanding PGP subkeys and their specific capabilities (S, E, A, C).
- Guidelines for strong passphrases and creating separate signing subkeys.

The translation maintains the 80-column limit and adheres to the
standard cryptographic terminology used in the Portuguese documentation
subsystem.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 Documentation/translations/pt_BR/index.rst    |   1 +
 .../pt_BR/process/maintainer-pgp-guide.rst    | 202 ++++++++++++++++++
 2 files changed, 203 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 4a094d8b7..3d3d42388 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -75,3 +75,4 @@ kernel e sobre como ver seu trabalho integrado.
    Processo do subsistema SoC <process/maintainer-soc>
    Conformidade de DTS para SoC <process/maintainer-soc-clean-dts>
    Processo do subsistema KVM x86 <process/maintainer-kvm-x86>
+   Guia de PGP para mantenedores <process/maintainer-pgp-guide>
diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
new file mode 100644
index 000000000..93f0759e9
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -0,0 +1,202 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+Guia de PGP para Mantenedores do Kernel Linux
+=============================================
+
+:Autor: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
+
+Este documento é voltado para desenvolvedores do kernel Linux, e especialmente
+para mantenedores de subsistemas. Ele contém um subconjunto das informações
+discutidas no guia mais geral "`Protegendo a Integridade do Código`_" publicado pela
+Linux Foundation. Leia esse documento para uma discussão mais aprofundada sobre
+alguns dos tópicos mencionados neste guia.
+
+.. _`Protegendo a Integridade do Código`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
+
+O papel do PGP no desenvolvimento do Kernel Linux
+=================================================
+
+O PGP ajuda a garantir a integridade do código que é produzido pela comunidade
+de desenvolvimento do kernel Linux e, em menor grau, a estabelecer canais de
+comunicação confiáveis entre desenvolvedores por meio da troca de e-mails
+assinados com PGP.
+
+O código-fonte do kernel Linux está disponível em dois formatos principais:
+
+- Repositórios de fontes distribuídos (git)
+- Arquivos tarballs por release
+
+Tanto os repositórios git quanto os tarballs carregam assinaturas PGP dos
+desenvolvedores do kernel que criam os lançamentos oficiais. Essas assinaturas
+oferecem uma garantia criptográfica de que as versões para download
+disponibilizadas via kernel.org ou em quaisquer outros espelhos são idênticas ao
+que esses desenvolvedores têm em suas estações de trabalho. Para esse fim:
+
+- repositórios git fornecem assinaturas PGP em todas as tags
+- tarballs fornecem assinaturas PGP avulsas com todos os downloads
+
+Confiar nos desenvolvedores, não na infraestrutura
+--------------------------------------------------
+
+Desde o comprometimento dos sistemas centrais do kernel.org em 2011, o
+princípio operacional principal do projeto Kernel Archives tem sido assumir
+que qualquer parte da infraestrutura pode ser comprometida a qualquer momento.
+Por este motivo, os administradores tomaram medidas deliberadas para enfatizar
+que a confiança deve ser sempre depositada nos desenvolvedores e nunca na
+infraestrutura de hospedagem de código, independentemente de quão boas sejam
+as práticas de segurança desta última.
+
+O princípio orientador acima é a razão pela qual este guia é necessário.
+Queremos garantir que, ao depositar confiança nos desenvolvedores, não
+estejamos meramente transferindo a culpa por potenciais incidentes de
+segurança futuros para outra pessoa. O objetivo é fornecer um conjunto de
+diretrizes que os desenvolvedores possam usar para criar um ambiente de
+trabalho seguro e proteger as chaves PGP usadas para estabelecer a integridade
+do próprio kernel Linux.
+
+Ferramentas PGP
+===============
+
+Use GnuPG 2.4 ou superior
+-------------------------
+
+Sua distribuição já deve ter o GnuPG instalado por padrão; você só precisa
+verificar se está usando uma versão razoavelmente recente dele. Para verificar,
+execute::
+
+    $ gpg --version | head -n1
+
+Se você tiver a versão 2.4 ou superior, está tudo pronto. Se tiver uma versão
+anterior, você está usando um lançamento do GnuPG que não é mais mantido e
+alguns comandos deste guia podem não funcionar.
+
+Configurar as opções do gpg-agent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+O agente GnuPG é uma ferramenta auxiliar que iniciará automaticamente sempre
+que você usar o comando ``gpg`` e rodará em segundo plano com o propósito de
+armazenar em cache a frase secreta (passphrase) da chave privada. Existem duas
+opções que você deve conhecer para ajustar quando a frase secreta deve expirar
+do cache:
+
+- ``default-cache-ttl`` (segundos): Se você usar a mesma chave novamente antes
+  que o tempo de vida expire, a contagem regressiva será reiniciada por outro
+  período. O padrão é 600 (10 minutos).
+- ``max-cache-ttl`` (segundos): Independentemente de quão recentemente você
+  tenha usado a chave desde a entrada inicial da frase secreta, se a contagem
+  regressiva do tempo de vida máximo expirar, você terá que digitar a frase
+  secreta novamente. O padrão é 30 minutos.
+
+Se você achar que qualquer um desses padrões é muito curto (ou muito longo),
+você pode editar seu arquivo ``~/.gnupg/gpg-agent.conf`` para definir seus
+próprios valores::
+
+    # definir 30 minutos para ttl regular, e 2 horas para o ttl máximo
+    default-cache-ttl 1800
+    max-cache-ttl 7200
+
+.. note::
+
+    Não é mais necessário iniciar o gpg-agent manualmente no início de sua
+    sessão de shell. Você pode querer verificar seus arquivos rc para remover
+    qualquer coisa que tenha configurado para versões mais antigas do GnuPG,
+    pois elas podem não estar mais agindo da forma correta.
+
+Proteja sua chave PGP
+=====================
+
+Este guia assume que você já possui uma chave PGP que utiliza para fins de
+desenvolvimento do kernel Linux. Se você ainda não possui uma, consulte o
+documento "`Protegendo a Integridade do Código`_" mencionado anteriormente para
+obter orientações sobre como criar uma nova.
+
+Você também deve criar uma nova chave se a sua atual for inferior a 2048
+bits (RSA).
+
+Você também deve criar uma nova chave se a sua atual for inferior a 2048
+bits (RSA).
+
+Entendendo as Subchaves PGP
+---------------------------
+
+Uma chave PGP raramente consiste em um único par de chaves -- geralmente é uma
+coleção de subchaves independentes que podem ser usadas para diferentes
+propósitos com base em suas capacidades, atribuídas no momento de sua criação.
+O PGP define quatro capacidades que uma chave pode ter:
+
+- As chaves **[S]** podem ser usadas para assinatura (*signing*)
+- As chaves **[E]** podem ser usadas para criptografia (*encryption*)
+- As chaves **[A]** podem ser usadas para autenticação (*authentication*)
+- As chaves **[C]** podem ser usadas para certificação de outras chaves
+  (*certifying*)
+
+A chave com a capacidade **[C]** é frequentemente chamada de chave "mestra",
+mas esta terminologia é enganosa porque implica que a chave de Certificação
+pode ser usada no lugar de qualquer outra subchave na mesma cadeia (como uma
+"chave mestra" física pode ser usada para abrir fechaduras feitas para outras
+chaves). Como este não é o caso, este guia irá referir-se a ela como "a chave
+de Certificação" para evitar qualquer ambiguidade.
+
+É fundamental compreender plenamente o seguinte:
+
+1. Todas as subchaves são totalmente independentes umas das outras. Se você
+   perder uma subchave privada, ela não poderá ser restaurada ou recriada a
+   partir de qualquer outra chave privada em sua cadeia.
+2. Com exceção da chave de Certificação, pode haver várias subchaves com
+   capacidades idênticas (ex: você pode ter 2 subchaves de criptografia
+   válidas, 3 subchaves de assinatura válidas, mas apenas uma subchave de
+   certificação válida). Todas as subchaves são totalmente independentes -- uma
+   mensagem criptografada para uma subchave **[E]** não pode ser
+   descriptografada com qualquer outra subchave **[E]** que você também possa
+   ter.
+3. Uma única subchave pode ter múltiplas capacidades (ex: sua chave **[C]**
+   também pode ser sua chave **[S]**).
+
+A chave que carrega a capacidade **[C]** (certificação) é a única chave que
+pode ser usada para indicar relacionamento com outras chaves. Apenas a chave
+**[C]** pode ser usada para:
+
+- adicionar ou revogar outras chaves (subchaves) com capacidades S/E/A
+- adicionar, alterar ou revogar identidades (uids) associadas à chave
+- adicionar ou alterar a data de expiração em si mesma ou em qualquer subchave
+- assinar chaves de outras pessoas para fins de rede de confiança (web of trust)
+
+Por padrão, o GnuPG cria o seguinte ao gerar novas chaves:
+
+- Uma subchave carregando as capacidades de Certificação e Assinatura (**[SC]**)
+- Uma subchave separada com a capacidade de Criptografia (**[E]**)
+
+Se você usou os parâmetros padrão ao gerar sua chave, então é isso que você
+terá. Você pode verificar executando ``gpg --list-secret-keys``, por exemplo::
+
+    sec   ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+          000000000000000000000000AAAABBBBCCCCDDDD
+    uid           [ultimate] Alice Dev <adev@kernel.org>
+    ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]
+
+A linha longa abaixo da entrada ``sec`` é o "fingerprint" (impressão digital)
+da sua chave -- sempre que você vir ``[fpr]`` nos exemplos abaixo, é a essa
+string de 40 caracteres que ele se refere.
+
+Certifique-se de que sua frase secreta seja forte
+-------------------------------------------------
+
+O GnuPG usa frases secretas para criptografar suas chaves privadas antes de
+armazená-las no disco. Dessa forma, mesmo que seu diretório ``.gnupg`` seja
+vazado ou roubado em sua totalidade, os invasores não poderão usar suas chaves
+privadas sem primeiro obter a frase secreta para descriptografá-las.
+
+É absolutamente essencial que suas chaves privadas sejam protegidas por uma
+frase secreta forte. Para defini-la ou alterá-la, use::
+
+    $ gpg --change-passphrase [fpr]
+
+Crie uma subchave de assinatura separada
+----------------------------------------
+
+Nosso objetivo é proteger sua chave de Certificação movendo-a para uma mídia
+offline; portanto, se você tiver apenas uma chave **[SC]** combinada, você deve
+criar uma subchave de assinatura separada::
+
+    $ gpg --quick-addkey [fpr] ed25519 sign
-- 
2.47.3

[PATCH v2 3/5] docs: pt_BR: continue PGP guide translation

[Daniel Pereira]

Translate the backup and smartcard-related sections of the PGP
maintainer guide into Brazilian Portuguese.

This update includes:
- Procedures for paperkey and full GnuPG directory backups.
- Guide for identifying keygrips and removing the Certify key from
  the local workstation for offline storage.
- Smartcard benefits, hardware options, and initial configuration.

The internal label 'smartcards' was renamed to 'smartcards_pt' to
avoid a global namespace conflict with the original English document
during the Sphinx build.

The file was verified with checkpatch.pl and passes with 0 errors
and 0 warnings.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/maintainer-pgp-guide.rst    | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)

diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index 93f0759e9..f7b312014 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -200,3 +200,292 @@ offline; portanto, se você tiver apenas uma chave **[SC]** combinada, você dev
 criar uma subchave de assinatura separada::
 
     $ gpg --quick-addkey [fpr] ed25519 sign
+
+Faça backup da sua chave de Certificação para recuperação de desastres
+----------------------------------------------------------------------
+
+Quanto mais assinaturas de outros desenvolvedores você tiver em sua chave PGP,
+mais motivos você terá para criar uma versão de backup que resida em algo que
+não seja mídia digital, por razões de recuperação de desastres.
+
+Uma boa maneira de criar uma cópia impressa da sua chave privada é usando o
+software ``paperkey``, escrito para este propósito específico. Veja
+``man paperkey`` para mais detalhes sobre o formato de saída e seus benefícios
+em relação a outras soluções. O Paperkey já deve estar empacotado para a
+maioria das distribuições.
+
+Execute o seguinte comando para criar um backup impresso da sua chave privada::
+
+    $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
+
+Imprima esse arquivo, pegue uma caneta e escreva sua frase secreta na margem do
+papel. **Isso é fortemente recomendado** porque a impressão da chave ainda
+está criptografada com essa frase secreta e, se você algum dia alterá-la, você
+não se lembrará de qual era quando criou o backup -- *garantido*.
+
+Coloque a cópia impressa resultante e a frase secreta escrita à mão em um
+envelope e guarde-os em um local seguro e bem protegido, de preferência longe
+de sua casa, como o cofre de um banco.
+
+.. note::
+
+    A chave ainda está criptografada com sua frase secreta, portanto, imprimir
+    mesmo em impressoras modernas "integradas à nuvem" deve continuar sendo uma
+    operação relativamente segura.
+
+Faça backup de todo o seu diretório GnuPG
+-----------------------------------------
+
+.. warning::
+
+    **!!!Não pule esta etapa!!!**
+
+É importante ter um backup prontamente disponível de suas chaves PGP caso
+precise recuperá-las. Isso é diferente da preparação para nível de desastre que
+fizemos com o ``paperkey``. Você também dependerá dessas cópias externas sempre
+que precisar usar sua chave de Certificação -- como ao fazer alterações em sua
+própria chave ou assinar as chaves de outras pessoas após conferências e
+encontros.
+
+Comece obtendo um cartão de mídia externa (de preferência dois!) que você usará
+para fins de backup. Você precisará criar uma partição criptografada neste
+dispositivo usando LUKS -- consulte a documentação de sua distribuição sobre
+como fazer isso.
+
+Para a frase secreta de criptografia, você pode usar a mesma de sua chave PGP.
+
+Assim que o processo de criptografia terminar, insira novamente o dispositivo e
+certifique-se de que ele foi montado corretamente. Copie todo o seu diretório
+``.gnupg`` para o armazenamento criptografado::
+
+    $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
+
+Você deve agora testar para garantir que tudo ainda funciona::
+
+    $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
+
+Se você não receber nenhum erro, então está tudo pronto. Desmonte o
+dispositivo, identifique-o claramente para não sobrescrevê-lo por acidente e
+guarde-o em um lugar seguro -- mas não muito longe, pois você precisará
+usá-lo de vez em quando para tarefas como editar identidades, adicionar ou
+revogar subchaves, ou assinar as chaves de outras pessoas.
+
+Remova a chave de Certificação de seu diretório pessoal
+-------------------------------------------------------
+
+Os arquivos em nosso diretório pessoal não estão tão bem protegidos quanto
+gostaríamos de pensar. Eles podem ser vazados ou roubados por meio de muitos
+meios diferentes:
+
+- por acidente ao fazer cópias rápidas do diretório pessoal para configurar
+  uma nova estação de trabalho
+- por negligência ou malícia do administrador de sistemas
+- por meio de backups mal protegidos
+- por meio de malware em aplicativos de desktop (navegadores, visualizadores
+  de PDF, etc.)
+- por meio de coação ao cruzar fronteiras internacionais
+
+Proteger sua chave com uma boa frase secreta ajuda muito a reduzir o risco
+de qualquer um dos itens acima, mas as frases secretas podem ser descobertas
+por meio de keyloggers, shoulder-surfing (observação direta) ou qualquer número
+de outros meios. Por este motivo, a configuração recomendada é remover sua
+chave de Certificação de seu diretório pessoal e armazená-la em um
+armazenamento offline.
+
+.. warning::
+
+    Consulte a seção anterior e certifique-se de que você fez o backup do seu
+    diretório GnuPG em sua totalidade. O que estamos prestes a fazer tornará
+    sua chave inútil se você não tiver um backup utilizável!
+
+Primeiro, identifique o "keygrip" da sua chave de Certificação::
+
+    $ gpg --with-keygrip --list-key [fpr]
+
+A saída será algo como isto::
+
+    pub   ed25519 2022-12-20 [SC] [expires: 2022-12-19]
+          000000000000000000000000AAAABBBBCCCCDDDD
+          Keygrip = 1111000000000000000000000000000000000000
+    uid           [ultimate] Alice Dev <adev@kernel.org>
+    sub   cv25519 2022-12-20 [E] [expires: 2022-12-19]
+          Keygrip = 2222000000000000000000000000000000000000
+    sub   ed25519 2022-12-20 [S]
+          Keygrip = 3333000000000000000000000000000000000000
+
+Encontre a entrada keygrip que está abaixo da linha ``pub`` (logo abaixo da
+impressão digital da chave de Certificação). Isso corresponderá diretamente a
+um arquivo em seu diretório ``~/.gnupg``::
+
+    $ cd ~/.gnupg/private-keys-v1.d
+    $ ls
+    1111000000000000000000000000000000000000.key
+    2222000000000000000000000000000000000000.key
+    3333000000000000000000000000000000000000.key
+
+É suficiente remover o arquivo .key que corresponde ao keygrip da chave de
+Certificação::
+
+    $ cd ~/.gnupg/private-keys-v1.d
+    $ rm 1111000000000000000000000000000000000000.key
+
+Agora, se você executar o comando ``--list-secret-keys``, ele mostrará que a
+chave de Certificação está faltando (o símbolo ``#`` indica que ela não está
+disponível)::
+
+    $ gpg --list-secret-keys
+    sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+          000000000000000000000000AAAABBBBCCCCDDDD
+    uid           [ultimate] Alice Dev <adev@kernel.org>
+    ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]
+    ssb   ed25519 2022-12-20 [S]
+
+Você também deve remover quaisquer arquivos ``secring.gpg`` no diretório
+``~/.gnupg``, que podem ser remanescentes de versões anteriores do GnuPG.
+
+Se você não tiver o diretório "private-keys-v1.d"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você não tiver um diretório ``~/.gnupg/private-keys-v1.d``, então suas
+chaves secretas ainda estão armazenadas no arquivo legado ``secring.gpg`` usado
+pelo GnuPG v1. Fazer qualquer alteração em sua chave, como mudar a frase
+secreta ou adicionar uma subchave, deve converter automaticamente o formato
+antigo ``secring.gpg`` para usar o ``private-keys-v1.d``.
+
+Assim que concluir isso, certifique-se de excluir o arquivo ``secring.gpg``
+obsoleto, que ainda contém suas chaves privadas.
+
+Mova as subchaves para um dispositivo criptográfico dedicado
+============================================================
+
+Embora a chave de Certificação agora esteja protegida contra vazamentos ou
+roubos, as subchaves ainda estão em seu diretório pessoal. Qualquer pessoa que
+consiga colocar as mãos nelas poderá descriptografar sua comunicação ou forjar
+suas assinaturas (se souberem a frase secreta). Além disso, cada vez que uma
+operação do GnuPG é realizada, as chaves são carregadas na memória do sistema e
+podem ser roubadas por malware suficientemente avançado (pense em Meltdown e
+Spectre).
+
+Uma boa maneira de proteger completamente suas chaves é movê-las para um
+dispositivo de hardware especializado que seja capaz de realizar operações de
+smartcard.
+
+Os benefícios dos smartcards
+----------------------------
+
+Um smartcard contém um chip criptográfico capaz de armazenar chaves privadas e
+realizar operações criptográficas diretamente no próprio cartão. Como o
+conteúdo da chave nunca sai do smartcard, o sistema operacional do computador
+no qual você conecta o dispositivo de hardware não é capaz de recuperar as
+próprias chaves privadas. Isso é muito diferente do dispositivo de
+armazenamento de mídia criptografado que usamos anteriormente para fins de
+backup -- enquanto esse dispositivo estiver conectado e montado, o sistema
+operacional poderá acessar o conteúdo da chave privada.
+
+O uso de mídia criptografada externa não substitui o uso de um dispositivo
+compatível com smartcard.
+
+Dispositivos smartcard disponíveis
+----------------------------------
+
+A menos que todos os seus laptops e estações de trabalho tenham leitores de
+smartcard, o mais fácil é obter um dispositivo USB especializado que implemente
+a funcionalidade de smartcard. Existem várias opções disponíveis:
+
+- `Nitrokey Start (pt)`_: Hardware aberto e Software Livre, baseado no `Gnuk_pt`_ da FSI
+  Japan. Uma das opções mais baratas, mas oferece menos recursos de segurança
+  (como resistência a violações ou alguns ataques de canal lateral).
+- `Nitrokey 3 (pt)`_: Semelhante ao Nitrokey Start, mas mais resistente a violações
+  e oferece mais recursos de segurança e formatos USB. Suporta criptografia ECC
+  (ED25519 e NISTP).
+- `Yubikey 5 (pt)`_: Hardware e software proprietários, mas mais barato que o
+  Nitrokey com um conjunto semelhante de recursos. Suporta criptografia ECC
+  (ED25519 e NISTP).
+
+Sua escolha dependerá do custo, da disponibilidade de envio em sua região
+geográfica e de considerações sobre hardware aberto ou proprietário.
+
+.. note::
+
+    Se você estiver listado em uma entrada `M:` no arquivo MAINTAINERS ou tiver
+    uma conta no kernel.org, você `se qualifica para um Nitrokey Start gratuito`_
+    cortesia da Linux Foundation.
+
+.. _`Nitrokey Start (pt)`: https://www.nitrokey.com/products/nitrokeys
+.. _`Nitrokey 3 (pt)`: https://www.nitrokey.com/products/nitrokeys
+.. _`Yubikey 5 (pt)`: https://www.yubico.com/products/yubikey-5-overview/
+.. _Gnuk_pt: https://www.fsij.org/doc-gnuk/
+.. _`se qualifica para um Nitrokey Start gratuito`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
+
+Configure seu dispositivo smartcard
+-----------------------------------
+
+Seu dispositivo smartcard deve simplesmente funcionar (Just Work - TM) no
+momento em que você o conecta em qualquer estação de trabalho Linux moderna.
+Você pode verificar executando::
+
+    $ gpg --card-status
+
+Se você vir os detalhes completos do smartcard, então está tudo pronto.
+Infelizmente, solucionar todos os possíveis motivos pelos quais as coisas
+podem não estar funcionando para você está muito além do escopo deste guia.
+Se você estiver tendo problemas para fazer a placa funcionar com o GnuPG,
+procure ajuda por meio dos canais usuais de suporte.
+
+Para configurar seu smartcard, você precisará usar o sistema de menus do GnuPG,
+pois não existem opções de linha de comando convenientes::
+
+    $ gpg --card-edit
+    [...omitido...]
+    gpg/card> admin
+    Comandos de administração são permitidos
+    gpg/card> passwd
+
+Você deve configurar o PIN de usuário (1), o PIN de Administrador (3) e o
+Código de Redefinição (4). Por favor, certifique-se de registrar e armazenar
+estes em um local seguro -- especialmente o PIN de Administrador e o Código de
+Redefinição (que permite limpar completamente o smartcard). Você raramente
+precisará usar o PIN de Administrador, de modo que inevitavelmente esquecerá
+o que é se não o registrar.
+
+Voltando ao menu principal do cartão, você também pode definir outros valores
+(como nome, gênero, dados de login, etc.), mas não é necessário e irá,
+adicionalmente, vazar informações sobre o seu smartcard caso você o perca.
+
+.. note::
+
+    Apesar de ter o nome "PIN", nem o PIN de usuário nem o PIN de administrador
+    no cartão precisam ser apenas números.
+
+.. warning::
+
+    Alguns dispositivos podem exigir que você mova as subchaves para o
+    dispositivo antes de poder alterar a frase secreta. Por favor, verifique a
+    documentação fornecida pelo fabricante do dispositivo.
+
+Mova as subchaves para o seu smartcard
+--------------------------------------
+
+Saia do menu do cartão (usando "q") e salve todas as alterações. Em seguida,
+vamos mover suas subchaves para o smartcard. Você precisará tanto da sua
+frase secreta da chave PGP quanto do PIN de administrador do cartão para a
+maioria das operações::
+
+    $ gpg --edit-key [fpr]
+
+    Secret subkeys are available.
+
+    pub  ed25519/AAAABBBBCCCCDDDD
+         created: 2022-12-20  expires: 2024-12-19  usage: SC
+         trust: ultimate      validity: ultimate
+    ssb  cv25519/1111222233334444
+         created: 2022-12-20  expires: never       usage: E
+    ssb  ed25519/5555666677778888
+         created: 2017-12-07  expires: never       usage: S
+    [ultimate] (1). Alice Dev <adev@kernel.org>
+
+    gpg>
+
+Usar ``--edit-key`` nos coloca no modo de menu novamente, e você notará que a
+listagem das chaves é um pouco diferente. De aqui em diante, todos os comandos
+são feitos de dentro deste modo de menu, conforme indicado por ``gpg>``.
-- 
2.47.3

[PATCH v2 4/5] docs: pt_BR: continue PGP guide: Git and maintenance

[Daniel Pereira]

Continue the PGP guide translation covering Git integration,
key maintenance, and the use of the patatt tool.

This update includes:
- Procedures for moving subkeys to hardware (keytocard) and verifying
  the transfer.
- PGP maintenance tasks: extending expiration dates and working with
  offline backups.
- Git configuration for signing tags and commits automatically.
- Introduction to agent forwarding over SSH and the patatt patch
  attestation tool.

Internal Sphinx labels (e.g., 'pgp_with_git', 'verify_identities') were
renamed with a '_pt' suffix to ensure a unique namespace and avoid
build warnings.

The file was verified with checkpatch.pl and passes with 0 errors
and 0 warnings.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/maintainer-pgp-guide.rst    | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)

diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index f7b312014..3501756fd 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -489,3 +489,292 @@ maioria das operações::
 Usar ``--edit-key`` nos coloca no modo de menu novamente, e você notará que a
 listagem das chaves é um pouco diferente. De aqui em diante, todos os comandos
 são feitos de dentro deste modo de menu, conforme indicado por ``gpg>``.
+
+Primeiro, vamos selecionar a chave que colocaremos no cartão -- você faz isso
+digitando ``key 1`` (é a primeira na listagem, a subchave **[E]**)::
+
+    gpg> key 1
+
+Na saída, você deverá ver agora ``ssb*`` na chave **[E]**. O ``*`` indica qual
+chave está atualmente "selecionada". Ele funciona como uma *alternância*
+(toggle), o que significa que se você digitar ``key 1`` novamente, o ``*``
+desaparecerá e a chave não estará mais selecionada.
+
+Agora, vamos mover essa chave para o smartcard::
+
+    gpg> keytocard
+    Please select where to store the key:
+       (2) Encryption key
+    Your selection? 2
+
+Como é a nossa chave **[E]**, faz sentido colocá-la no slot de Criptografia
+(Encryption). Quando você enviar sua seleção, será solicitada primeiro a frase
+secreta da sua chave PGP e, em seguida, o PIN de administrador. Se o comando
+retornar sem erros, sua chave foi movida.
+
+**Importante**: Agora digite ``key 1`` novamente para desmarcar a primeira chave
+e ``key 2`` para selecionar a chave **[S]**::
+
+    gpg> key 1
+    gpg> key 2
+    gpg> keytocard
+    Please select where to store the key:
+       (1) Signature key
+       (3) Authentication key
+    Your selection? 1
+
+Você pode usar a chave **[S]** tanto para Assinatura quanto para Autenticação,
+mas queremos garantir que ela esteja no slot de Assinatura, então escolha (1).
+Mais uma vez, se o seu comando retornar sem erros, a operação foi
+bem-sucedida::
+
+    gpg> q
+    Save changes? (y/N) y
+
+Salvar as alterações excluirá as chaves que você moveu para o cartão de seu
+diretório pessoal (mas não há problema, pois as temos em nossos backups caso
+precisemos fazer isso novamente para um smartcard de substituição).
+
+Verificando se as chaves foram movidas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você executar ``--list-secret-keys`` agora, verá uma diferença sutil na
+saída::
+
+    $ gpg --list-secret-keys
+    sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+          000000000000000000000000AAAABBBBCCCCDDDD
+    uid           [ultimate] Alice Dev <adev@kernel.org>
+    ssb>  cv25519 2022-12-20 [E] [expires: 2024-12-19]
+    ssb>  ed25519 2022-12-20 [S]
+
+O ``>`` na saída ``ssb>`` indica que a subchave está disponível apenas no
+smartcard. Se você voltar ao diretório de chaves secretas e observar o
+conteúdo, notará que os arquivos ``.key`` foram substituídos por stubs::
+
+    $ cd ~/.gnupg/private-keys-v1.d
+    $ strings *.key | grep 'private-key'
+
+A saída deve conter ``shadowed-private-key`` para indicar que esses arquivos
+são apenas stubs e o conteúdo real está no smartcard.
+
+Verificando se o smartcard está funcionando
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para verificar se o smartcard está funcionando conforme o esperado, você pode
+criar uma assinatura::
+
+    $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
+    $ gpg --verify /tmp/test.asc
+
+Isso deve solicitar o PIN do seu smartcard no primeiro comando e, em seguida,
+mostrar "Good signature" após você executar ``gpg --verify``.
+
+Parabéns, você conseguiu tornar extremamente difícil o roubo da sua identidade
+digital de desenvolvedor!
+
+Outras operações comuns do GnuPG
+--------------------------------
+
+Aqui está uma referência rápida para algumas operações comuns que você
+precisará realizar com sua chave PGP.
+
+Montando seu armazenamento offline seguro
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você precisará da sua chave de Certificação para qualquer uma das operações
+abaixo, portanto, primeiro precisará montar seu armazenamento offline de backup
+e dizer ao GnuPG para usá-lo::
+
+    $ export GNUPGHOME=/media/disk/foo/gnupg-backup
+    $ gpg --list-secret-keys
+
+Certifique-se de ver ``sec`` e não ``sec#`` na saída (o símbolo ``#``
+significa que a chave não está disponível e você ainda está usando o local
+padrão do seu diretório pessoal).
+
+Estendendo a data de expiração da chave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A chave de Certificação tem uma data de expiração padrão de 2 anos a partir da
+data de criação. Isso é feito tanto por razões de segurança quanto para fazer
+com que chaves obsoletas eventualmente desapareçam dos servidores de chaves
+(keyservers).
+
+Para estender a expiração da sua chave em um ano a partir da data atual, basta
+executar::
+
+    $ gpg --quick-set-expire [fpr] 1y
+
+Você também pode usar uma data específica se for mais fácil de lembrar (por
+exemplo, seu aniversário ou 1º de janeiro)::
+
+    $ gpg --quick-set-expire [fpr] 2038-07-01
+
+Lembre-se de enviar a chave atualizada de volta para os servidores de chaves::
+
+    $ gpg --send-key [fpr]
+
+Atualizando seu diretório de trabalho após alterações
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Depois de fazer qualquer alteração em sua chave usando o armazenamento offline,
+você desejará importar essas alterações de volta para o seu diretório de
+trabalho normal::
+
+    $ gpg --export | gpg --homedir ~/.gnupg --import
+    $ unset GNUPGHOME
+
+Usando gpg-agent sobre SSH
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você pode encaminhar seu gpg-agent sobre SSH se precisar assinar tags ou
+commits em um sistema remoto. Por favor, consulte as instruções fornecidas
+na wiki do GnuPG:
+
+- `Encaminhamento de Agent sobre SSH (pt)`_
+
+Funciona de forma mais fluida se você puder modificar as configurações do
+servidor sshd na extremidade remota.
+
+.. _`Encaminhamento de Agent sobre SSH (pt)`: https://wiki.gnupg.org/AgentForwarding
+
+Usando PGP com Git
+==================
+
+Uma das principais características do Git é sua natureza descentralizada --
+uma vez que um repositório é clonado em seu sistema, você tem o histórico
+completo do projeto, incluindo todas as suas tags, commits e branches. No
+entanto, com centenas de repositórios clonados por aí, como alguém verifica
+se sua cópia do linux.git não foi adulterada por um terceiro mal-intencionado?
+
+Ou o que acontece se um código malicioso for descoberto no kernel e a linha
+"Author" no commit disser que foi feito por você, enquanto você tem certeza
+de que `não teve relação com isso (pt)`_?
+
+Para resolver ambas as questões, o Git introduziu a integração com PGP. Tags
+assinadas provam a integridade do repositório, garantindo que seu conteúdo é
+exatamente o mesmo que estava na estação de trabalho do desenvolvedor que
+criou a tag, enquanto commits assinados tornam quase impossível para alguém
+se passar por você sem ter acesso às suas chaves PGP.
+
+.. _`não teve relação com isso (pt)`: https://github.com/jayphelps/git-blame-someone-else
+
+Configure o git para usar sua chave PGP
+---------------------------------------
+
+Se você tiver apenas uma chave secreta em seu chaveiro, não precisará fazer
+nada extra, pois ela se torna sua chave padrão. No entanto, se você tiver
+várias chaves secretas, poderá informar ao git qual chave deve ser usada
+(``[fpr]`` é a impressão digital da sua chave)::
+
+    $ git config --global user.signingKey [fpr]
+
+Como trabalhar com tags assinadas
+---------------------------------
+
+Para criar uma tag assinada, passe a opção ``-s`` para o comando tag::
+
+    $ git tag -s [tagname]
+
+Nossa recomendação é sempre assinar as tags do git, pois isso permite que outros
+desenvolvedores garantam que o repositório git do qual estão baixando não foi
+alterado de forma maliciosa.
+
+Como verificar tags assinadas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para verificar uma tag assinada, use o comando ``verify-tag``::
+
+    $ git verify-tag [tagname]
+
+Se você estiver baixando (pulling) uma tag de outro fork do repositório do
+projeto, o git deve verificar automaticamente a assinatura na ponta (tip) que
+você está baixando e mostrar os resultados durante a operação de merge::
+
+    $ git pull [url] tags/sometag
+
+A mensagem de merge conterá algo como isto::
+
+    Merge tag 'sometag' of [url]
+
+    [Tag message]
+
+    # gpg: Signature made [...]
+    # gpg: Good signature from [...]
+
+Se você estiver verificando a tag git de outra pessoa, primeiro precisará
+importar a chave PGP dela. Por favor, consulte a seção
+":ref:`verificar_identidades_pt`" abaixo.
+
+Configure o git para sempre assinar tags anotadas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+É provável que, se você estiver criando uma tag anotada, você desejará
+assiná-la. Para forçar o git a sempre assinar tags anotadas, você pode definir
+uma opção de configuração global::
+
+    $ git config --global tag.forceSignAnnotated true
+
+Como trabalhar com commits assinados
+------------------------------------
+
+Também é possível criar commits assinados, mas eles têm utilidade limitada no
+desenvolvimento do kernel Linux. O fluxo de trabalho de contribuição do kernel
+depende do envio de patches, e a conversão de commits em patches não preserva
+as assinaturas de commit do git. Além disso, ao fazer o rebase do seu próprio
+repositório em um upstream mais recente, as assinaturas PGP de commit acabarão
+sendo descartadas. Por esse motivo, a maioria dos desenvolvedores do kernel não
+se preocupa em assinar seus commits e ignorará commits assinados em quaisquer
+repositórios externos nos quais dependam para o seu trabalho.
+
+Dito isso, se você tem sua árvore git de trabalho disponível publicamente em
+algum serviço de hospedagem git (kernel.org, infradead.org, ozlabs.org ou
+outros), a recomendação é que você assine todos os seus commits do git, mesmo
+que os desenvolvedores upstream não se beneficiem diretamente dessa prática.
+
+Recomendamos isso pelos seguintes motivos:
+
+1. Caso haja necessidade de realizar uma análise forense de código ou rastrear a
+   proveniência do código, mesmo as árvores mantidas externamente contendo
+   assinaturas PGP de commit serão valiosas para tais fins.
+2. Se você precisar clonar novamente seu repositório local (por exemplo, após
+   reinstalar seu sistema), isso permite verificar a integridade do repositório
+   antes de retomar seu trabalho.
+3. Se alguém precisar fazer o cherry-pick dos seus commits, isso permite que
+   verifiquem rapidamente a integridade deles antes de aplicá-los.
+
+Criando commits assinados
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para criar um commit assinado, passe a flag ``-S`` para o comando
+``git commit`` (é um ``-S`` maiúsculo devido à colisão com outra flag)::
+
+    $ git commit -S
+
+Configure o git para sempre assinar commits
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você pode informar ao git para sempre assinar os commits::
+
+    git config --global commit.gpgSign true
+
+.. note::
+
+    Certifique-se de configurar o ``gpg-agent`` antes de ativar esta opção.
+
+.. _verificar_identidades_pt:
+
+Como trabalhar com patches assinados
+------------------------------------
+
+É possível usar sua chave PGP para assinar patches enviados para as listas de
+discussão de desenvolvedores do kernel. Como os mecanismos existentes de
+assinatura de e-mail (PGP-Mime ou PGP-inline) tendem a causar problemas com as
+tarefas regulares de revisão de código, você deve usar a ferramenta que o
+kernel.org criou para este fim, que coloca assinaturas de atestação
+criptográfica nos cabeçalhos das mensagens (estilo DKIM):
+
+- `Atestação de Patch Patatt (pt)`_
+
+.. _`Atestação de Patch Patatt (pt)`: https://pypi.org/project/patatt/
-- 
2.47.3

[PATCH v2 5/5] docs: pt_BR: complete PGP guide translation

[Daniel Pereira]

Finish the translation of the PGP maintainer guide into Brazilian
Portuguese, covering advanced tools and identity verification.

This final part adds:
- Detailed configuration for the patatt patch attestation tool.
- Integration of gpg-agent with SSH for remote signing.
- Procedures for verifying kernel developer identities.
- Technical overview of WOT (Web of Trust) vs. TOFU models.
- Automated key discovery via WKD and DANE (DNSSEC/TLS).
- Usage of the kernel.org PGP keyring repository.

All internal cross-references and labels were updated with the '_pt'
suffix to maintain a clean namespace during the Sphinx build.

The document passes checkpatch.pl with 0 errors/warnings and builds
perfectly with 'make htmldocs'.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/maintainer-pgp-guide.rst    | 133 ++++++++++++++++++
 1 file changed, 133 insertions(+)

diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index 3501756fd..fd19fd4c9 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -778,3 +778,136 @@ criptográfica nos cabeçalhos das mensagens (estilo DKIM):
 - `Atestação de Patch Patatt (pt)`_
 
 .. _`Atestação de Patch Patatt (pt)`: https://pypi.org/project/patatt/
+
+Instalando e configurando o patatt
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note::
+
+    Se você usa o B4 para enviar seus patches, o patatt já está instalado
+    e integrado ao seu fluxo de trabalho.
+
+O patatt já está empacotado para muitas distribuições, portanto, verifique-as
+primeiro. Você também pode instalá-lo a partir do pypi usando
+"``pip install patatt``".
+
+Se você já tem sua chave PGP configurada com o git (via o parâmetro de
+configuração ``user.signingKey``), o patatt não requer nenhuma configuração
+adicional. Você pode começar a assinar seus patches instalando o hook do
+git-send-email no repositório que desejar::
+
+    patatt install-hook
+
+Agora, quaisquer patches que você enviar com ``git send-email`` serão
+automaticamente assinados com sua assinatura criptográfica.
+
+Verificando assinaturas do patatt
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você estiver usando o ``b4`` para recuperar e aplicar patches, ele tentará
+verificar automaticamente todas as assinaturas DKIM e patatt que encontrar,
+por exemplo::
+
+    $ b4 am 20220720205013.890942-1-broonie@kernel.org
+    [...]
+    Checking attestation on all messages, may take a moment...
+    ---
+      ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
+      ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
+      ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
+      ---
+      ✓ Signed: openpgp/broonie@kernel.org
+      ✓ Signed: DKIM/kernel.org
+
+.. note::
+
+    O patatt e o b4 ainda estão em desenvolvimento ativo e você deve consultar
+    a documentação mais recente desses projetos para quaisquer recursos novos
+    ou atualizados.
+
+Como verificar identidades de desenvolvedores do kernel
+=======================================================
+
+Assinar tags e commits é simples, mas como verificar se a chave usada para
+assinar algo pertence ao desenvolvedor real do kernel e não a um impostor
+mal-intencionado?
+
+Configurar a recuperação automática de chaves usando WKD e DANE
+---------------------------------------------------------------
+
+Se você ainda não possui uma vasta coleção de chaves públicas de outros
+desenvolvedores, pode dar um pontapé inicial em seu chaveiro confiando na
+autodescoberta e recuperação automática de chaves. O GnuPG pode se apoiar em
+outras tecnologias de confiança delegada, especificamente DNSSEC e TLS, para
+ajudá-lo se a perspectiva de começar sua própria teia de confiança (Web of Trust)
+do zero for muito desanimadora.
+
+Adicione o seguinte ao seu ``~/.gnupg/gpg.conf``::
+
+    auto-key-locate wkd,dane,local
+    auto-key-retrieve
+
+O DANE (DNS-Based Authentication of Named Entities) é um método para publicar
+chaves públicas no DNS e protegê-las usando zonas assinadas por DNSSEC. O WKD
+(Web Key Directory) é o método alternativo que usa consultas https para o mesmo
+propósito. Ao usar DANE ou WKD para buscar chaves públicas, o GnuPG validará o
+DNSSEC ou os certificados TLS, respectivamente, antes de adicionar as chaves
+públicas recuperadas automaticamente ao seu chaveiro local.
+
+O Kernel.org publica o WKD para todos os desenvolvedores que possuem contas
+kernel.org. Uma vez que você tenha as alterações acima em seu ``gpg.conf``, você
+poderá recuperar automaticamente as chaves de Linus Torvalds e Greg
+Kroah-Hartman (caso ainda não as tenha)::
+
+    $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
+
+Se você tem uma conta kernel.org, deve `adicionar o UID do kernel.org à sua chave (pt)`_
+para tornar o WKD mais útil para outros desenvolvedores do kernel.
+
+.. _`adicionar o UID do kernel.org à sua chave (pt)`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
+
+Web of Trust (WOT) vs. Trust on First Use (TOFU)
+------------------------------------------------
+
+O PGP incorpora um mecanismo de delegação de confiança conhecido como "Teia de
+Confiança" (Web of Trust - WOT). Em sua essência, trata-se de uma tentativa de
+substituir a necessidade de Autoridades de Certificação centralizadas do mundo
+HTTPS/TLS. Em vez de vários fabricantes de software ditarem quem deve ser sua
+entidade certificadora de confiança, o PGP deixa essa responsabilidade para cada
+usuário.
+
+Infelizmente, pouquíssimas pessoas entendem como a Teia de Confiança funciona.
+Embora ainda seja uma parte importante da especificação OpenPGP, as versões
+recentes do GnuPG (2.2 e superiores) implementaram um mecanismo alternativo
+chamado "Confiança no Primeiro Uso" (Trust on First Use - TOFU). Você pode
+pensar no TOFU como "a abordagem de confiança estilo SSH". Com o SSH, na primeira
+vez que você se conecta a um sistema remoto, o fingerprint da chave dele é
+gravado e lembrado. Se a chave mudar no futuro, o cliente SSH o alertará e se
+recusará a conectar, forçando-o a tomar uma decisão sobre confiar ou não na
+chave alterada. Da mesma forma, na primeira vez que você importa a chave PGP de
+alguém, assume-se que ela é válida. Se em algum momento no futuro o GnuPG se
+deparar com outra chave com a mesma identidade, tanto a chave importada
+anteriormente quanto a nova chave serão marcadas para verificação, e você
+precisará descobrir manualmente qual delas manter.
+
+Recomendamos que você use o modelo de confiança combinado TOFU+PGP (que é o novo
+padrão no GnuPG v2). Para configurá-lo, adicione (ou modifique) a configuração
+``trust-model`` em ``~/.gnupg/gpg.conf``::
+
+    trust-model tofu+pgp
+
+Usando o repositório Web of Trust do kernel.org
+-----------------------------------------------
+
+O kernel.org mantém um repositório git com as chaves públicas dos
+desenvolvedores como um substituto para as redes de servidores de chaves
+(keyservers) que ficaram em grande parte inativas nos últimos anos. A
+documentação completa sobre como configurar esse repositório como sua fonte de
+chaves públicas pode ser encontrada aqui:
+
+- `Chaveiro PGP de desenvolvedores do Kernel (pt)`_
+
+Se você é um desenvolvedor do kernel, considere enviar sua chave para inclusão
+nesse chaveiro.
+
+.. _`Chaveiro PGP de desenvolvedores do Kernel (pt)`: https://korg.docs.kernel.org/pgpkeys.html
-- 
2.47.3