Bug 326322

Summary: kgpg generates new RSA&RSA keys as SCEA/SEA instead of SC/E
Product: [Applications] kgpg Reporter: info
Component: generalAssignee: Rolf Eike Beer <kde>
Status: REPORTED ---    
Severity: normal CC: dkg
Priority: NOR    
Version First Reported In: 2.10.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
URL: https://gpgtools.lighthouseapp.com/projects/66001/tickets/65-gpg-gen-key-with-default-settings-produces-incorrect-sceasea-usage-keys-with-rsa-schemes
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description info 2013-10-20 13:16:56 UTC 
kgpg generates new RSA keys with wrong properties having SCEA/SEA. Commandline gpg generates keys as SC/E.

Reproducible: Always

Steps to Reproduce:
1. Create a new RSA & RSA key in kgpg.
2. Get the ID of the newly created key with gpg -k
3.  gpg --edit-key YOURID showpref quit
4. --> Actual results
5. Create a new RSA & RSA key with gpg --gen-key or kgpg expert mode.
6. Get the ID of the newly created key with gpg -k
7.  gpg --edit-key YOURID showpref quit
8. --> Expected results
Actual Results:  
pub 2048R/xxx usage: SCEA
sub 2048R/yyy usage: SEA

Expected Results:  
pub 2048R/xxx usage: SC
sub 2048R/yyy usage: E


MacGPG 2.0.18 was also affected from this problem: https://gpgtools.lighthouseapp.com/projects/66001/tickets/65-gpg-gen-key-with-default-settings-produces-incorrect-sceasea-usage-keys-with-rsa-schemes
Comment 1 Rolf Eike Beer 2013-10-20 14:17:50 UTC 
I have GnuPG 2.0.19, and the flags after generation are SCA and E.
Comment 2 Daniel Kahn Gillmor 2015-10-28 16:22:40 UTC 
Using gpg 2.1.9, i see SCEA for the primary and SEA for the subkey.  This is not advisable.   Users should avoid using the same key for both signing and encryption, and tools should not encourage this behavior.

The simplest fix would just be to use gpg's defaults and leave all the rest of the fiddliness  to an expert mode.
Comment 3 Justin Zobel 2021-03-09 23:51:18 UTC 
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.