<div dir="ltr">OK, we are making progress. Thank you.<br><br>We used this page to rid ourselves of obsolete bad keys:<br><a href="http://stuff-things.net/2015/04/22/gpg-public-key-of-ultimately-trusted-key-00000000-not-found/">http://stuff-things.net/2015/04/22/gpg-public-key-of-ultimately-trusted-key-00000000-not-found/</a><br><br>We continue to have trust level problems. When adding _all_ new keys from our clients, we always assign level 4 (fully) to each.<br><br>On the legacy (v2.0.22) host, it looks like this:<br># /usr/bin/gpg --list-keys 571F553F<br>pub 2048R/571F553F 2023-07-10 [expires: 2025-10-09]<br>uid FISERV-SFG-NA-PROD-GPG-2K-23-193-01 (FISERV SFG NA PROD GPG 2K) <<a href="mailto:X3GDS_FDFileGateway@fiserv.com">X3GDS_FDFileGateway@fiserv.com</a>><br>sub 2048R/C71BDCEC 2023-07-10 [expires: 2025-10-09]<br><br>However, on the new host (v2.3.3) the output is different:<br># /usr/bin/gpg --list-keys 571F553F<br>pub rsa2048 2023-07-10 [SC] [expires: 2025-10-09]<br> 41261F6446B51FDBD18FDDF8C4D62F13571F553F<br>uid [ unknown] FISERV-SFG-NA-PROD-GPG-2K-23-193-01 (FISERV SFG NA PROD GPG 2K) <<a href="mailto:X3GDS_FDFileGateway@fiserv.com">X3GDS_FDFileGateway@fiserv.com</a>><br>sub rsa2048 2023-07-10 [E] [expires: 2025-10-09]<br><br>Encrypting a file using that key, for example, fails thusly:<br>gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named user<br><br>The only solution we've found is to _manually_ edit each public key, and assign level 5 (ultimate) - which we are loathe to do.<br><br>We do not want every key at level ultimate, and we do not want to manually edit hundreds of keys to change each trust level.<br><br>What are we missing?<br><br>Please, advise. Thank you.<br><br>~ Mike<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 9, 2024 at 11:30 AM Werner Koch <<a href="mailto:wk@gnupg.org">wk@gnupg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 8 Oct 2024 13:09, Mike Schleif said:<br>
<br>
> Ought we do something on the legacy (v2.0.22) host before copying to the<br>
> new host?<br>
<br>
I general not but you can do this:<br>
<br>
gpg --export >all-public-keys.gpg<br>
gpg --export-secret-keys >all-secret-keys.gpg<br>
gpg --export-ownertrust >ownertrust.txt<br>
<br>
also backup the *.conf files if you have some.<br>
<br>
On the new machine rename the existsing ~/.gnupg to ~/.gnupg-saved and<br>
then run<br>
<br>
gpg -k<br>
<br>
which will create a new ~/.gnupg<br>
<br>
Then<br>
<br>
gpg --import <all-secret-keys.gpg<br>
gpg --import <all-public-keys.gpg<br>
gpg --import-ownertrust <ownertrust.txt<br>
gpg --check-trustdb<br>
<br>
That avoids any problem with garbage inthe ~/.gnupg. Check gpg.conf<br>
whether you have any strange keys in them. Inb particular remove any<br>
references to the old PGP-2 keys.<br>
<br>
<br>
Shalom-Salam,<br>
<br>
Werner<br>
<br>
-- <br>
The pioneers of a warless world are the youth that<br>
refuse military service. - A. Einstein<br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><br>If ever I can be of service to you; contact me at once.<br>I wish for you a truly extraordinary day ...<br><br>-- <br>Best Regards,<br><br>Mike Schleif<br>612-235-6060<div><a href="https://mikeschleif.net" target="_blank">https://mikeschleif.net</a><br><a href="http://mdsresource.net" target="_blank">http://mdsresource.net</a><br><a href="http://www.linkedin.com/in/schleif" target="_blank">http://www.linkedin.com/in/schleif</a><br><a href="http://facebook.com/MDSResource" target="_blank">http://facebook.com/MDSResource</a><br><a href="http://twitter.com/mikeschleif" target="_blank">http://twitter.com/mikeschleif</a></div></div></div>