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
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 6 2021
Jan 5 2021
Jan 4 2021
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.
Jul 16 2020
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.
May 8 2020
I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.
Apr 23 2020
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).
May 5 2019
Jun 18 2018
It's in 2.2.4 and 1.4.23.
Closing.
Jun 12 2018
ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.
Jun 11 2018
Jun 8 2018
@dkg can you please take this up with Debian and other distros? See the commit for a brief description.
May 2 2018
Apr 13 2018
Applied to STABLE-BRANCH-1-4, too.
Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.
Feb 5 2018
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.
Feb 3 2018
Some enlightenments here because i may have not mention some info in the first place :
Feb 2 2018
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?
Feb 1 2018
Nov 21 2017
It's fixed in master.
It is good to backport this to GnuPG 2.2 and GnuPG 1.4.
Nov 1 2017
OK, closed.
Oct 24 2017
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.
Oct 22 2017
Same issue exists in 2.2:
Oct 20 2017
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
Aug 15 2017
It's been a month since last release, no error reports so far.
Aug 9 2017
Aug 7 2017
No worries :)
Aug 5 2017
Done with commit rGa69464b0b6da.
ah, great! sorry i got confused :)
Aug 4 2017
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.
Jul 26 2017
gpg 1.4 only gets important updates.
Jul 21 2017
Jul 19 2017
I just released 1.4.22 including the usual Windows installer. No anouncement mail but I added an entry to the NEWS page.
Jul 17 2017
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.
Jul 11 2017
Jul 4 2017
Should be fixed in 782f804765b6f4226fd77843e59f57dcca61b6fb, can you verify that? Thanks!
Jul 2 2017
For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.
Jul 1 2017
Jun 23 2017
Any updates / thoughts on how this might be fixed?
Jun 22 2017
Jun 7 2017
Marcus, can you please check this?
May 10 2017
Patch applied and pushed to STABLE-BRANCH-1-4.
Apr 26 2017
I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org
Apr 11 2017
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.
Apr 4 2017
Mar 30 2017
Mar 2 2017
Feb 5 2017
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
Jan 23 2017
Jan 16 2017
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)
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.
Jan 6 2017
A major problem with gpg FILE-WITH-KEYS is that its behaviour was never well
defined and it is more a side effect than a a reguarl feature.
It should be fixed, however.
Nov 30 2016
Oct 6 2016
Sep 14 2016
Indeed, this is unfortunate, but not as bad as you make it sound (unless the
user uses always trust).
Note that this is not about signing (which uses the private key), but about
encryption. I've changed the bug title accordingly.
This happens also with master, and it seems the order of keys in the public
keyring is important:
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.TR2cSoWHMb/pubring.kbx' created
gpg: /tmp/tmp.TR2cSoWHMb/trustdb.gpg: trustdb created
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: 1A7265CF27F9E78E: There is no assurance this key belongs to the named user
sub rsa2048/1A7265CF27F9E78E 2016-09-14 test.user@example.org
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Primary key fingerprint: CA77 8656 2AAC BBB2 6A50 3A50 8D62 594F 1FE9 0C7B
Subkey fingerprint: 52CB E9DC 1812 9F78 3054 6569 1A72 65CF 27F9 E78E
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
130 teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export
GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.Hfjbb2jvji/pubring.kbx' created
gpg: /tmp/tmp.Hfjbb2jvji/trustdb.gpg: trustdb created
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: DAB278A8736B0D2C: There is no assurance this key belongs to the named user
sub rsa2048/DAB278A8736B0D2C 2016-09-14 user@example.org
Primary key fingerprint: 6680 B181 D853 CEB5 6671 ECC7 0098 8FEC 00B5 CA77
Subkey fingerprint: 3909 7C31 399C A746 87B3 5D74 DAB2 78A8 736B 0D2C
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting