Patrick Brunschwig wrote: > AFAICT there is no workaround for this, unless you switch to the "regular" > Enigmail mode until that's solved.
I’ve found no way to disable the spurious key generation, except preventing gpg
itself from creating new keys. I tried switching to "regular" Enigmail mode.
It’s possible I failed to do so correctly of course. As I wrote :
> > If you go to [account] -> View settings for this account -> OpenGPG
> > Security and then click the Enable OpenPGP security Enigmail toggle box
> > then you may select to use a specific key, but this setting appears to be
> > ignored and sometimes gets erased later.
> > As an aside, anytime you click this box it asks if you want to disable
> > pEp, but clicking cancel still checks the box, so you must uncheck it and
> > click cancel again.
Claudio Luck wrote:
> > although the email address is not set to be the primary uid
> Thank you very much! I have a feeling that your pointer is what I needed
to proceed on this issue.
I reordered my keys based upon this suggestion, but the spurious keys still get
generated.
I did however recall unusual features of my GPG key:
First, I’ve sometimes kept my certificate C key offline, so my key has a
separate online signing subkey S, along with the usual encryption subkeys.
This practice might theoretically simplify recovery from compromised online
subkeys. I’ve largely given this practice up, but my key still has two signing
keys. And I might go back to doing it.
Is it possible pEp gets confused by the presence of a second signing subkey?
My key looks like this:
sec rsa4096/0x07D3102EF1A1B9AD 2015-06-02 [SC]
Key fingerprint = 6AEF 11CA 09DE 806E 69D3 7097 07D3 102E F1A1 B9AD
uid [ultimate] Jeffrey Burdges <[email protected]>
uid [ultimate] Jeffrey Burdges <[email protected]>
uid [ultimate] Jeffrey Burdges <[email protected]>
ssb rsa4096/0xABAC7FD1CC100A74 2015-06-02 [S] [expires: 2020-04-15]
ssb rsa4096/0x676A2B0597AF8568 2015-06-02 [E] [expires: 2020-04-15]
ssb rsa4096/0xA74AF253D057FFD8 2015-06-02 [E]
A key generated by pEp looks like this:
sec rsa2048/0xCB32F44F6D77B1A2 2018-04-30 [SC] [expires: 2019-04-30]
Key fingerprint = A835 22C9 38E8 901C 9443 B875 CB32 F44F 6D77 B1A2
uid [ultimate] Jeff Burdges <[email protected]>
ssb rsa2048/0xE7C5549194D0FE03 2018-04-30 [E] [expires: 2019-04-30]
I can reimport the first key pEp generated to prevent pEp generating more:
sec rsa2048/0xEC3788D35F51960B 2018-04-19 [SC] [expires: 2019-04-19]
Key fingerprint = 814C 5A35 6801 A39D 35D4 487D EC37 88D3 5F51 960B
uid [ unknown] Jeff Burdges <[email protected]>
ssb rsa2048/0xEA11FFE14865ABEC 2018-04-19 [E] [expires: 2019-04-19]
You’ll notice the “unknown” trust setting here, so trust settings do not appear
to cause any problems.
Second, I only have my [email protected] email going through Thunderbird, so
maybe pEp gets confused because it sees it cannot access all those email
addresses? Just fyi, I do this because the web3.foundation is actually a
gmail, and so requires a SOCKS proxy for location privacy, while the gnu
project ones get direct IMAP.
Best,
Jeff
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ enigmail-users mailing list [email protected] To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
