Sure. Thanks for testing. The problem with new versions is that ppl don't like to test release candidates and thus we need do real releases and wait for the outfall. ;-)
Tue, Jan 26
Sat, Jan 23
Wed, Jan 20
Fixed by jukvilli’s patch.
That works, thanks. So does that become part of the next release?
Fri, Jan 8
The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.
Thu, Jan 7
Thanks. I added the OIDs and the missing curves. To go into 1.9
Wed, Jan 6
Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.
Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.
After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html
Tue, Jan 5
Mon, Jan 4
Thus better add a && !defined(clang)
Sure that the FreeBSD compiler does not define it? I am pretty sure it does.
According to list of attributes in the clang 12 documention, there is no such attribute in clang. However, the clang-11 compiler (as seen in Debian) does not define __GNUC__, so the proposed patch does not affect the status when building with clang.
You may want to check that clang supports this attribute as well.
May 8 2020
Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0
Apr 25 2020
Mar 18 2020
I checked the code and your patch looks right. I am going to apply it.
Feb 6 2020
Thanks. Fix goes into 1.37.
Dec 5 2019
Nov 11 2019
See also D475.
Nov 7 2019
Oct 15 2019
Sep 9 2019
Jun 6 2019
Here are the patches without any new commands:
@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?
Jun 5 2019
In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.
May 29 2019
May 28 2019
May 27 2019
@werner Thank you for resolving this issue.
See the man page on how to delete subkeys or just the primary secret key with --delete-key.
May 22 2019
Actually I have a different approach to fix this bug(let). Please give me a few days.
May 21 2019
In master, I pushed a change, closing.
For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.
May 9 2019
It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:
May 8 2019
Apr 30 2019
Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.
Please explain in more detail what the problem with Cygwin is.
Apr 29 2019
I've applied your patch with an additional comment to our master branch. Thanks!
Apr 9 2019
We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Apr 5 2019
Apr 3 2019
Mar 27 2019
Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com
Mar 26 2019
From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25
fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.
Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.
Feb 10 2019
Patch applied, thanks.
Patch applied, thanks.
Feb 8 2019
Jan 28 2019
fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.
That is a very interesting problem that we did not have on our radar.
Jan 25 2019
Jan 23 2019
Jan 21 2019
I've developed a simple patch that sets the CREATE_BREAKAWAY_FROM_JOB flag when creating a new background process. This flag requires a special permission on the job object, which is tested first. This means that the patch only works if the parent process sets JOB_OBJECT_LIMIT_BREAKAWAY_OK on the job object, otherwise the behavior should be as without the patch.
Oct 15 2018
Just commited. Thanks.
Jun 18 2018
On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:
The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.
Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)