DANE has been an experimental thing and is imho dead.

Thanks for the report. However, for 1.4 we will only apply important real world security patches. A brief review did not reveal any setious problems. Theoretical memory leaks will not be fixed. Note that your report also includes patches to parts of the code which are not anymore used.

Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

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

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.

Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.

I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.

Thanks. I tried to install the latest released version, 1.4.23, but I got the same error.

That is a very old version (2015); please retry using the latest released version 1.4.23 (from 2018).

It's in 2.2.4 and 1.4.23.
Closing.

ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

@dkg can you please take this up with Debian and other distros? See the commit for a brief description.

Applied to STABLE-BRANCH-1-4, too.

Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.

FYI : when submitting a buffer composed of

• a leading 00 byte,
• the 255 bytes encrypted session key value

to HSM/PKCS11 for decyption, decrypt returns without any errors, and returned plain session key is the one expected.

Some enlightenments here because i may have not mention some info in the first place :

Our HSM is a certified FIPS 140-2, sec level3, hardware module, exposing a PKCS#11 v2.30 spec compliant API.

What kind of hardware token?

It's fixed in master.
It is good to backport this to GnuPG 2.2 and GnuPG 1.4.

OK, closed.

Won't we fixed for 1.4 and 2.0 (which is too close to EOL). Has been fixed for master; see T2359.

GnuPG 1.4 is only for old features. New features are only supported by GnuPG 2.2.

Same issue exists in 2.2:

Won't be fixed for 1.4.

There should be a backup file in these cases.

I would suggest to close this as won't fix.

In 2.2 we implemented --import-option show-only which dies the right thing, that is to use the reguarl key-listing code. Backporting this to 1.4 does not make sense - people should move on and use gpg 2.2.

Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?

This patch was released with 1.4.22

It's been a month since last release, no error reports so far.

No worries :)

Done with commit rGa69464b0b6da.

ah, great! sorry i got confused :)

I only removed the documentation in the STABLE-BRANCH-1-4. Nobody said we want to remove this feature, and it is still documented in STABLE-BRANCH-2-0 and master.

fwiw, faked-system-time is used in several non-gnupg packages in debian already.

I just removed the paragraph (gpgtwoone is not used anymore anyways). Fixed in eb15d5ed8.

gpg 1.4 only gets important updates.

I just released 1.4.22 including the usual Windows installer. No anouncement mail but I added an entry to the NEWS page.

gpg 1.4 will now only receive important updates, and this is a change in behavior, which might break scripts.

I just verified that this is indeed fixed.

Should be fixed in 782f804765b6f4226fd77843e59f57dcca61b6fb, can you verify that? Thanks!

For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.

Any updates / thoughts on how this might be fixed?

Marcus, can you please check this?

Patch applied and pushed to STABLE-BRANCH-1-4.

I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org

Please use GnuPG 2 (2.0 or 2.1) for using smartcard/token.
smartcard support in GnuPG 1.4 is way old and only supports shorter key length.

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Attached example output after patch is applied. Now User4 has full validity like
expected, and the debug output shows a match for User4's email address (NOTE:
the debug output has 'YES' for no match and 'NO' for successful match)

D406: 944_example.patch

Attached example patch prevents escaping normal lowercase letters.

Note that this isn't a general solution, though it does solve the issue for me.
For example, some email addresses have numbers (I don't know if having backslash
before numbers is an issue like it is for letters)

Attached example are the following setup:

user1 tsign user2 with full trust, depth 1, domain="customer.com". User2 signs
user3 through user5 (regular signatures). User4 is at customer.com, users 3 and
5 are at example.com.