Bugs, feature requests, memos, and support related to GnuPG.
Note that the tags gnug24, gnupg26 etc are used to indicate that a certain task is scheduled to be fixed in that version. This tag here is used if there is no concrete version affected or a schedule has not yet been set.
I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key
Verified.
Thank you for your report.
Pushed the change: rGaf6c47b2910f: common,kbx,tests: Clean up the PIPE function API.
Push the change: rG953dd67368ce: Use gpgrt_process_spawn API from libgpg-error.
Please test.
Thank you for your report. We are about to migrate to use the gpgrt_spawn_process API.
(In our development history, it was originally implemented and tested as gnupg_spawn_process API and moved to libgpg-error.)
In case you run into problems installing the bzip2 part w/o root rights, you need to apply rGc333e9dad66 to set the PREFIX make variable also for bzip2.
Thank you for the patch.
Reading the original bug report it is clear that this is not a gpg bug but a problem in the Python code. This should only be read as utf-8 if the NOTATION_FLAGS line indicated that this is human readable.
Since it is only me, let us set the "Wishlist" priority on this task.
For my testing environment, I have this patch for now.
All applied and more fun with cherry picking in the future ;-)
Recall that on windows you have a current working directory per drive. Thus only LETTER:\foo is a full patch - or an UNC (\\SERVER\foo).
The executable is on Z: drive (Z:\home\gniibe\build\mingw-i686\gnupg\agent\gpg-agent.exe) in the emulated environment.
Perhaps, when the path is absolute path with /, it is interpreted as on the drive Z:.
fwiw, i've just shipped a patch to correct this change in behavior in the 2.2 branch debian. Many thanks to @gniibe , on whose work in the 2.4 branch this is based, and to @ametzler1, who did the backporting to 2.2. I've also written a test which tries to tickle this bug. It fails with unpatched 2.2.43 as emacs times out signing and encrypting mail as epg.el deadlocks with gpg.
All fine. I just noticed it while checking the patch. All applied and more fun with cherry picking in the future ;-)
that looks like it was a problem in the original text, not something i introduced. If you find anything else that needs fixing, please go ahead and fix it to! no need to wait for me.
It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.
In more than 25 years of OpenPGP we only had a few new implementations which got it wrong. I see no need to fix it here - maybe import could indeed reject such a key, though.
Maybe there's a 4th possible option that's better than the three i identified?
So i see a range of ways that any OpenPGP software could deal with this:
Right away the first patch:
I can replicate that and it works if you disable the use of the CRT. Looking at the key:
pkey[0]: BC9E1CD66676208956B35357210C220508F9F883FE32F4D682CD36BFB4E8055938D4BA21C341D9F48527E420F951B80335B24DF6710F01C4364D554AF659FC35D322061B67CC2F303DC878076059E4F266CFAEF6AB7A29124E969B9C15B1FC2FBA0F0F90E6B059E36B5E3C9BEC4174162689108A1E0EF6D5DDEE61B6B48327A259746288A517B1D78A0E24F5EFF6E880FF39C0BEDDC464B66F787B559EC5487F248196C2CFB15730BD9695C48355DFB2839FA23D8A37FBD48C741F6BE19F9D48BF844C5147591E1E06803DA40BEA1186B3B39CDCBC0E7DAC9DACDBB60A20E56B7E6631E47A45989A256743FDD83C591CFD4110DEA1B04ADE91CCB575FB858C13 pkey[1]: 010001 skey[2]: 512FB977EB9872FECA8BDB96884A01A6AB2B7575D307B9ED4F55E777F2F55FBFFCBF4BF2D669D4D7F42CAC7C28F4ACC0ECEEF7B1D90E3D936850372352107F87E77E20A4D133C927F99FFD52277DEA17107BDA72A072AF950AB0B70023327E3B48D9CCB871237D3D6F6C9BA7FDB45AB46217E33FA01A8ED295795323E26505BC9471CAE4DDA94DBF4F35ED915B0CD025805DCA796EB6B208D8D3F63DBE52BC0045CF4CF9B128356359C7E55B661D7B9DCA57F8984095C5AD3FE4DBD19228B281D66609A154DD7E3EE940CFC66CC180DDC4DD00C45A52D5789286D89D49CA34E5F3C4E798D90955074DAE3D99F7F004CDFFBC9B8428E8EB603E240AE07BEE8D71 skey[3]: F57D9F597750967DF272D9AC661DDC212D7C5CA4C6E91573A80756281351CDC3A2532B155D9251029F89A0A0807DF2BD177DC30FC6A847E07738B55606DF032ADAD8361E0AFEE9C0CF7D566793834977FAAE9C4B87132B94F665EFF463777CDE7EB89113FA3AAC194B6F2D30C40BE7C0DDE36A5855277C1E4D0204FC4C737BCB skey[4]: C4B135296B8F4390B953DDA84249FC8467CFF81FC715D1B5F3E01FCC8DC770813630AEA93982F2004705C4D272E07A10B1882AC5C09A45E88B14A1446B4C639B549420CE3BF90947E6E86503E426A8FDAC4C5CFC2809F5F0A1647ED5EE2457C054A40AA1F0666B28B2C970BE2093AE7B095A688B2D713CA8885826F23AFB37D9 skey[5]: 0790A8E260C6CADC353FB3961D798EFD4F15F96752DA20B86841334C38861743DD7A1FEB2B750D0864F5901BE541B6C8FB63649B18FDC4A32A1233EF90872DCD35704A4B4063DB62752CF6A7FD00F086C6B1042A2B0CB6FB36B7D5269671DACF55242A838E60D514BA868354910CEB1C41FB9A43BF932B5036A6EFE35236FFC7