Attached is the script I am using to acceptance test the suite. It requires
Clang 3.5 (Clang 3.5 recipe was provided with Bug 1872).

Closing. My script overwrote the symbol/optimizations with the Clang flags.

Changed status to 'unread'. I am not chatting.

Attached is the script I am using to acceptance test the suite. It requires
Clang 3.5 (Clang 3.5 recipe was provided with Bug 1872)

Attached is the script I am using to acceptance test the suite. It requires
Clang 3.5 (Clang 3.5 recipe was provided with Bug 1872).

27503==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:

#0 0x49f53b in malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x53a9ca in _gcry_private_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x53a9ca)

#2 0x4f2e00 in do_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f2e00)

#3 0x4f289a in _gcry_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f289a)

#4 0x4f5349 in _gcry_xmalloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f5349)

#5 0xc7ade0 in _gcry_mpi_alloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0xc7ade0)

#6 0xc8c6ac in _gcry_mpi_set_ui

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0xc8c6ac)

#7 0x4c9d2b in gcry_mpi_set_ui

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4c9d2b)

#8 0x4bd295 in test_const_and_immutable

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4bd295)

#9 0x4bd0fb in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4bd0fb)

#10 0x2abeb5528ec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Indirect leak of 8 byte(s) in 1 object(s) allocated from:

#0 0x49f53b in malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x53a9ca in _gcry_private_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x53a9ca)

#2 0x4f2e00 in do_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f2e00)

#3 0x4f289a in _gcry_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f289a)

#4 0x4f5349 in _gcry_xmalloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4f5349)

#5 0xc7b998 in _gcry_mpi_alloc_limb_space

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0xc7b998)

#6 0xc7aef4 in _gcry_mpi_alloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0xc7aef4)

#7 0xc8c6ac in _gcry_mpi_set_ui

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0xc8c6ac)

#8 0x4c9d2b in gcry_mpi_set_ui

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4c9d2b)

#9 0x4bd295 in test_const_and_immutable

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4bd295)

#10 0x4bd0fb in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/mpitests+0x4bd0fb)

#11 0x2abeb5528ec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).
FAIL: mpitests
./tsexp: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information
available (required by ./tsexp)

27510==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 558 byte(s) in 1 object(s) allocated from:

#0 0x49f53b in malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x548dfa in _gcry_private_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x548dfa)

#2 0x501230 in do_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x501230)

#3 0x500cca in _gcry_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x500cca)

#4 0x50fffa in _gcry_sexp_find_token

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x50fffa)

#5 0x4d62cb in gcry_sexp_find_token

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4d62cb)

#6 0x4cc1ad in bug_1594

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4cc1ad)

#7 0x4bcf62 in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4bcf62)

#8 0x2ad398718ec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Direct leak of 523 byte(s) in 1 object(s) allocated from:

#0 0x49f53b in malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x548dfa in _gcry_private_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x548dfa)

#2 0x501230 in do_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x501230)

#3 0x500cca in _gcry_malloc

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x500cca)

#4 0x50fffa in _gcry_sexp_find_token

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x50fffa)

#5 0x4d62cb in gcry_sexp_find_token

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4d62cb)

#6 0x4cc295 in bug_1594

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4cc295)

#7 0x4bcf62 in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/tsexp+0x4bcf62)

#8 0x2ad398718ec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: 1081 byte(s) leaked in 2 allocation(s).
FAIL: tsexp

27657==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 144560 byte(s) in 278 object(s) allocated from:

#0 0x49f690 in calloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:56:3

#1 0x4c3020 in do_slope_benchmark

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c3020)

#2 0x4d2030 in cipher_bench_one

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4d2030)

#3 0x4c6565 in _cipher_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c6565)

#4 0x4c5d96 in cipher_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c5d96)

#5 0x4cb103 in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4cb103)

#6 0x2b9df664dec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Direct leak of 15080 byte(s) in 29 object(s) allocated from:

#0 0x49f690 in calloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:56:3

#1 0x4c3020 in do_slope_benchmark

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c3020)

#2 0x4cc4ea in mac_bench_one

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4cc4ea)

#3 0x4c86db in _mac_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c86db)

#4 0x4c819a in mac_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c819a)

#5 0x4cb0ef in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4cb0ef)

#6 0x2b9df664dec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Direct leak of 9360 byte(s) in 18 object(s) allocated from:

#0 0x49f690 in calloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:56:3

#1 0x4c3020 in do_slope_benchmark

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c3020)

#2 0x4cfd7a in hash_bench_one

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4cfd7a)

#3 0x4c773b in _hash_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c773b)

#4 0x4c6e0a in hash_bench

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4c6e0a)

#5 0x4cb0db in main

(/home/gpg-user/gcrypt-2.0-sanitize/libgcrypt-1.6.3/tests/bench-slope+0x4cb0db)

#6 0x2b9df664dec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: 169000 byte(s) leaked in 325 allocation(s).
FAIL: bench-slope

The following still harbors undefined behavior, but I did not want to touch it
due to fears of breaking the zeoizer:

cipher-gcm.c:1144:7: runtime error: store to misaligned address...
cipher-gcm.c:1145:7: runtime error: store to misaligned address...
cipher-gcm.c:1146:7: runtime error: store to misaligned address...

      wipememory (c->u_mode.gcm.tagiv, GCRY_GCM_BLOCK_LEN);
      wipememory (c->u_mode.gcm.aadlen, sizeof (c->u_mode.gcm.aadlen));
      wipememory (c->u_mode.gcm.datalen, sizeof (c->u_mode.gcm.datalen));

cipher-ccm.c:280:7: runtime error: store to misaligned address...

wipememory (c->u_mode.ccm.macbuf, 16);

Updated bufhelp that corrects the undefined behavior.

Updated gost28147 that corrects the undefined behavior.

And:

$ addr2line -e libgcrypt-1.6.3/tests/version 0x51d8c6
hwf-x86.c:?

And:

$ gdb
(gdb) file libgcrypt-1.6.3/tests/version
Reading symbols from libgcrypt-1.6.3/tests/version...done.
(gdb) info symbol 0x51d8c6
get_xgetbv + 294 in section .text
(gdb) info *0x51d8c6
Undefined info command: "*0x51d8c6". Try "help info".
(gdb) info line *0x51d8c6
No line number information available for address 0x51d8c6 <get_xgetbv+294>

Related bug: "Test suite built without symbols",
T1873.

Attached is the recipe I am using to build Clang 3.5.

It appears --disable-static is the culprit.

Pretty please take this discussion to the public, i.e. gnupg-users. And please
stop re-changing priority values.

Platform: Red Hat Enterprise Linux 5.11

ldconfig: I did not (assuming that make install does it if necessary)

Running "sudo ldconfig" after each "sudo make install" does not help.

You stated that you deliberately used a self-signed SSL cert instead of
buying one, because, in your own words, "The X.509 system is broken beyond
repair."

That is a political reason, and is has reduced user security. Using non-
working SSL reduces security - you do know that, don't you?

The *reason* security gets "broken beyond repair", is because too many
people change mistakes into "notbug" and never fix stuff.

Bite your tongue, swallow your pride, spend the $3.50 and just buy a
certificate mate.

This conversation is going to get read by other people in future, you decide
next what you want them to think about you.

Some may want such an option, please discuss at gnupg-users and re-open this bug
if the conclusion is that there needs to be a way to ignore the preferred keyserver.

Just a last remark: You have an encrypted connection which protects you from
passive easvesdropping of the password. Securing agains active attacks is much
harder and thus useless. The only thing we need to protect is the password
which in turn is only used as an anti-spam measure. All information in the
tracker are public anyway.

I have not reduced the "security" of anything for political reasons.
This discussion does not belong into a bug tracker - please use gnupg-users
instead. Thanks.

What platform? Did you run ldconfig after installing a library?

I really want to try, but I cannot compile 2.1.2 due to T1862.

In what other ways have you "on purpose" reduced the security of your users
for tin-foil-hat political reasons I wonder?

Buy the cert. It's, like, $3.50 (comodo), or if you really want to splurge,
$49 for unlimited number of domains and SANs and wildcards and whatever else
tickles your fancy (startssl)

Compiling with latest npth instead of latest pth does not change anything.
Without patch = segfault, with patch = works.

I do not think that such an option is useful. Please feel free to discuss at
gnupg-users to get other opinions.

Duplicate of T1644

Okay, I changed your role so that you can comment on T1644.

It is very unlikely that we are going to fix that in 2.0, thus be prepared to
move to 2.1.

That is actually on purpose. The X.509 system is broken beyond repair. It is
just not SECURE. The only thing you get is protection against passive
eavesdropping (if at all).

However, given all these complinats it might be easier to pay for a certificate.
I will consider this but first the tracker needs to be moved to another box.

Wow. I didn't even know that was a thing. What's weirder is --keyserver doesn't
override it. Shouldn't the user be able to override it somehow?

Yes, I understand that keyids are not unique. However, when I ask for the
fingerprint of a key, I likely mean the primary key, not subkeys. People use
keyids (hopefully long, often short), or fingerprints as an identity... and they
always mean of their primary key, not their subkeys. There should be an option
to list only primary keys that match.

Thanks. It might be related to a left overPGP-2 key in the trustdb. I need to
investigate that closer.

gpg --check-sigs --list-options show-keyserver-urls BEB441496300CC3D
[...]
sig!3 BEB441496300CC3D 2011-02-15 Jeremy Kitchen (Systems

   Preferred keyserver: hkp://subkeys.pgp.net/

The key itself specifies preferred keyserver which overrides a standard keyserver.

keyids are not unique. The short keyid of the subkey of the second key matches
the keyid of the first key and thus both are listed.

It is just warning which does not matter if you are using a released tarball.
The next release will support newer autotools and has updated helper files.