This is an automated email from the ASF dual-hosted git repository.
exceptionfactory pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/nifi-site.git
The following commit(s) were added to refs/heads/main by this push:
new 21322c4 NIFI-11683 Adjusted wording of GPG section on Key Transfer
21322c4 is described below
commit 21322c4749e85f599949695573fcb67aeb773c4d
Author: exceptionfactory <[email protected]>
AuthorDate: Wed Jun 14 14:56:01 2023 -0500
NIFI-11683 Adjusted wording of GPG section on Key Transfer
---
source/gpg.md | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/source/gpg.md b/source/gpg.md
index 1cefd89..00546d4 100644
--- a/source/gpg.md
+++ b/source/gpg.md
@@ -502,40 +502,50 @@ In this case, you should contact the RM and report this
finding.
## <a name="transfer-a-secret-key">Transfer a secret key</a>
-This is a risky operation. The most vulnerable part of the system is the
passphrase that encrypts the private key. If an attacker obtains a copy of the
encrypted private key file, an attack on the passphrase is likely to be
feasible. So it is vital to store the private key securely at all times.
-There are very few occasions when this risk is justified. One of them is when
you need to transfer your key to a new machine.
+Transferring a secret key requires careful consideration to maintain security.
+The most vulnerable part of the system is the passphrase that encrypts the
private key.
+The security of an encrypted private key is based on the strength of the
associated passphrase, so it is vital to store the private key securely at all
times.
+
+Run the following command to export all secret keys to a temporary file with
ASCII Armor encoding:
-To export all secret keys to a temporary file:
```
gpg --export-secret-keys --armor --output exported_keys.sec
```
-Move `exported_keys.sec` to the new machine, preferably with a pendrive.
+Move `exported_keys.sec` to the new machine, preferably using an external
drive.
Import this temporary file into the target keyring:
+
```
gpg --import exported_keys.sec
```
Check for secret keys imported in the output. Listing secret keys for the
target keyring should now show the existence of the secret key:
+
```
gpg --list-secret-keys
```
-Finally make sure that the temporary file you used cannot be read. We
recommend secure deletion. If you are working on Linux, for example, you can
use the `shred` command:
+Delete the temporary keys file using a secure deletion method. If you are
working on Linux, for example, you can use the `shred` command:
+
```
shred exported_keys.sec
```
-The keys you exported most likely had `ultimate` trust by default, because you
generated them. However the trust level is not exported, so the key going to
have `unknown` trust.
+The keys you exported most likely had `ultimate` trust by default, because you
generated them.
+However, the trust level is not exported, so the key going to have `unknown`
trust.
To restore `ultimate` trust, you need to edit the key `gpg --edit-key <keyId>`
by typing `trust` command in the prompt.
-Another option is to export the trustlevel of your keys:
+Another option for restoring the trust level is to export the information and
then import it on the new system.
+
+Run the following command to export the current trust level:
+
```
gpg --export-ownertrust > trustlevel.txt
```
-To import them:
+Run the following command to import the trust level information:
+
```
gpg --import-ownertrust < trustlevel.txt
```
