Ok here is the output:

C:\Users\croll>gpg --import "Desktop\Charles Rollins.asc"
gpg: key C7EE3D25FF2E5EF5: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: key C7EE3D25FF2E5EF5: failed to re-lookup public key
gpg: key C7EE3D25FF2E5EF5: public key "Charles Rollins
<crollinsphoto@gmail.com>" imported
gpg: Total number processed: 2
gpg: w/o user IDs: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 4 signed: 9 trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1 valid: 9 signed: 0 trust: 1-, 0q, 0n, 0m, 8f, 0u
gpg: next trustdb check due at 2019-11-05

C:\Users\croll>

What is meant by missing self signature? I signed it before exporting it.

And attached is a test key.

• test.asc13 KBDownload

The test.asc is the concatenation of two armored PGP keyblocks. The first is a secret key block and the second a public key block. The secret key block includes all information from the public key block and thus only the secret key block is required. BUT: The secret key block is not standard conform because it does not include any binding signature (neither for the user-id nor for the subkey).

You may use an editor to split the file into its two parts and the import the public key first (this has probably already been done). Then you can try to import the first part using

gpg --allow-non-selfsigned-uid --import -v FILE

But I have some doubts that it will work. It is possible to manually import it by fixing the secret keyblock: Copt the two parts int two separate directories, then run

gpg --dearmor <FILE >FILE.new
gpgsplit FILE.new

in both directories. In the directory with the public key you should see these files:

000001-006.public_key
000002-013.user_id
000003-002.sig
000004-014.public_subkey
000005-002.sig
000006-014.public_subkey
000007-002.sig

In the other directory you will see less files because the .sig files are missing. Copy the file 000001-005.secret_key over 00001-0006.public_key, the file 00003-007.secret_subkey over 00004-014.public_subkey and 00004-007.secret_key over 000006-014.public_subkey.
Then concatenate them all:

cat 00000{1,2,3,4,5,6,7}-* >secretkey.pgp

and import the latter. I have not tested this, though. gpgsplit should also be available on Windows. Instead of the cat command you need to use "copy /b", I forgot about the concrete syntax, though. Remember that these files are binary.

Ok, yeah trying to import separately did not work, still refuses the
secret key. The key should be valid because it was created a few days
ago in the pgp desktop 10.3.2 program. BUT if I import the entire
keyring (.skr) file ALL my secret keys are imported with no problem
which cannot be done for keys I make for others.

All the other info you told me is like greek to me, I do not understand
a bit of it.

So is there a way you can make gpg accept it? Since apparently the pgp
desktop is probably being used by a lot of people and it is only a
matter of time until someone tries to import it into Thunderbird and
faces the same problem. I used to us Microsoft Outlook and their
openpgp plugin "Encryptomatic" accepts the key with no problem. So is
there a way you can come out with a new version that will accept these keys?

Oh my,.. I tested it myself with the very latest PGP Desktop version and this is really what you get as output.

Here is my test key which is basically the same.

WTF. @crollinsphoto : This is really a bug in PGP Desktop.
@werner: Any chance we can improve here? I mean we want people to migrate from PGP Desktop to Gpg4win,.. so it sucks that they break it.

Glad you duplicated it. I sure hope you can fix it. Good luck.

Do you think you can do it with a new gnupg?

Charles

Checking the OpenPGP specs again, there is actually an "exit" clause for this PGP bug. Or well, what I would consider to be a bug. A fix for this is not easy because it would require to detect this at an outer level (the ascii armor) which we don't do because gpg is build along a streaming concept as almost all Unix tools. What we can do is to allow import of a secret key in that PGP format iff a public key is already there. In practise this would mean to run the import two times and ignore the errors from the first import.

@aheinecke: Do you think we can also do something in the GUI part to make this easier. For example detection of that double armor thing and Try a second time?

Yes, I think that if I see an import result with "secret-keys-read && w/o userId's" I can just do a second try.

Ok. Let me know so I can try it out.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

FWIW, for testing I used the current code and had --rfc4880bis enabled. That also enables --allow-non-selfsigned-uid which is the reason why I noticed slightly different behaviour.

Where can I get the new thing file to install?

So where can I get the corrected file to install? I suppose I need the
new gpg4win, it hasn't been updated yet. If I need the signature or TAR
from your website how can I implement that?

Charles

When will the new gnupg program be released so I can install it?

Charles

We are aiming for this week.

Great. Thank you.

Great. Let me know when the newest gpg4win is released.