Yes, I forgot to include the full build log, I'm attaching it here. I've seen this in OpenSUSE Tumbleweed; the compiler is gcc10; and I can see this on any architecture. The test fails when building against gpg-2.2.21 but not with previous versions.
Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.
While I see that it's not the matter of actual use case (but how gpg can be immune to fuzzing), code clean up would be good here.
Thu, Jul 9
Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.
gpg has code to make sure that a new key is at least one second newer than the previous generated.
I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.
The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.
Or this (don't allow anon keys for different usage):
diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c index 14cbdbb0f..b8d4059cd 100644 --- a/g10/pubkey-enc.c +++ b/g10/pubkey-enc.c @@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek) if (err) break;
Do you mean something like this?
Wed, Jul 8
Mon, Jul 6
Thu, Jul 2
Fixed; In master the code already uses our generic scheme parser.
I edited the task and now you can edit it too.
could you please change the edit policy back to all users so that I can change the status of this task?
I don't think this fix has made it into a release yet. Could we get a released version of gpgme that contains this fix?
Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.
Wed, Jul 1
on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.
I think this might be the issue with High DPI support problems. T4819 which is not yet released.
Some information of Qt5 about -fpic:
Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400
Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.
I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.
Tue, Jun 30
I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.
Thanks for your report.
Mon, Jun 29
Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?