I will look into it when I am back from vacation.

Fixed by commit 92fa5f16d69707e302c0f85b2e5e80af8dc037f1

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=92fa5f16d69707e302c0f85b2e5e80af8dc037f1

No DCO received, no review, won't apply. Sorry.

To be considered for 1.7

We can consider that for 1.7.
Can you please send a DCO to gcrypt-devel (see doc/HACKING).

Sorry, we won't do that.

(Please do not try to continue a discussion here but take it to gcrypt-devel
instead - but I doubt that you will convince us).

The problem seems to be segmentation fault in tests/basic. The provided
information is not sufficient for a closer look. You need to help us by
debugging the core file to get at least backtrace.

However, I would suggest to report this to this Homebrew thingie and to try
wityh the latest libgcrypt (1.6.3, but 1.6.4 will be release soon)

Fixed for 1.6.4 with commit 59058aac.

Fix for master backported for 1.6.4 with commit 67d93a2.

We should really do that for 1.7. SHA512 is important enough these days to
require a 64 bit type.

Jussi: Do we consider this as no-bug?

This is the same as T1881

Duplicate of T1881

Applied for 1.6.4 and master

It is a common practise to use enums instead of macros to help debugging code.
In fact the GNU coding standard suggest this use.

It is also common practise for *C* code to use int and enums interchangable.
Right, we use an unsigned int but that is justified because we do not have
negative values.

The only problem I am ware of is the OS/2 (and maybe also the AIX) compiler
which makes the internal size of an enum type depend on the largest use value
(e.g. a 16 bit short instead of a 32 bit int). However, this is rarely a
problem and gpg_err_code_t anyway requires more than 16 bits.

If you can tell me an option for xlc to disable the warnings/error I can add
this to configure script. A pragma would also do.

The GIT master and also the 1.6 branch now has a fix for that problem. A 1.6.4
release sill be done soon.

AESNI is enabled in the gnupg 2.1 installer which we will use with gpg4win 3.0

This problem still occurs with libgcrypt from current master:
libgcrypt 1.7.0-beta259

#0 0x655f24a7 in _gcry_aes_aesni_do_setkey (ctx=0x97f868,

key=0x656621b4 <key_128>

"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>) at rijndael-aesni.c:117

Ooops - I should know it is my installer :-(
1.6.3.

Done

Could I be granted a user role so I can do additional work with the bug tracker?

Hi,

I think having a different agent for different values of GNUPGHOME is correct
behavior. It is desirable as it increases isolation.

What version of GnuPG are you using? (You filed this bug report against
libgcrypt.) Did you build from source? What distribution?

Thanks.

You are not supposed to run autoreconf.

The version string match bug was fixed in master and 1.6 branch.

Thank you, patch applied to master and 1.6 branch.

That is a very old gnupg version - You better update GnuPG to 2.0.27 and
Libgcrypt to 1.6.3.

Hi Werner,

Thnaks very much for the support.

The version we are using is as below
gpg --version
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,

CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

If we update our libgcrypt 1.4.5 to 1.6.0 will it work for us to decrypt the
PGP file which is encrypted with idea algorithm

The patents on IDEA was one of the major reasons to write GnuPG and thus to
avoid IDEA. Meanwhile the IDEA patent expired and Libgcrypt supports it. Thus
if you update to a decent version of Libgcrypt this works for you. Libgcrypt
must be >= 1.6.0. You may also use GnuPG 1.4.14 which also includes IDEA.

Please some one help on this issue. This is little bit critical

Duplicate of T1936

See also T1974.

[I granted you the User role (see https://bugs.gnupg.org)]

Probably, T1936 will a duplicate of this issue.
Create a new issue so I could not comment on the issue...

D299: 603_bug494740.patch

sevan@NetBSD.org just reported that it is needed on Solaris 10, otherwise
linking libgcrypt.so fails with:

Undefined first referenced

symbol in file

__udiv_qrnnd ./.libs/libgcrypt.so

ld: fatal: symbol referencing errors. No output written to .libs/mpicalc

collect2: ld returned 1 exit status

So please apply the change after all.

Thank you for further information.
Now, I understand your situation of mixture of architectures.
I think that your source code was once configured by 32-bit environment (which
created links to 32-bit), and then you tried to configure and to compile by
64-bit environment which caused errors.

I think that "make distclean; configure; make" would success even on the 32-bit
environment with different host OS.

libgcrypt compiles fine on regular FreeBSD 10.1 with the proper
architecture. The problem with the mismatched architecture was because
I was on a virtual machine and I had to run a 32 bit OS in the machine
because my 64-bit hardware didn't have hardware virtualization and
would only run a 32-bit OS. I guess that situation isn't too common,
but I'll leave it to you to classify the original report as a bug or
converted feature request/idea.

It seems for me that your build environment is not clean and has some links for
i386, while your arch is x86_64. It is i386's mpih-add1 which has ALIGN(3) at
line number 44.

Please do 'make distclean' and configure, then make.

This is related to the "ALIGN (3)" mpi code that caused a compile
problem on FreeBSD 10.1 (I changed it to "ALIGN (2)" and it compiled,
but I'm not sure if that will break something).

We did not changed anything in this code for many many years. This seems to be
a configure problem: The configure script (actually mpi/config.links) figured
that you are using BSD_SYNTAX but in reality as(1) requires ELF_SYNAX.

What is the cpu-os-vendor string? Look at mpi/asm-syntax.h in the build
directory - the top 3 lines shows this.

be an as(1) problem.

FWIW: libgpg-error.so.0: no version information available"
is a harmless diagnostic issued for example by Debian to help detecting broken
ABIs. It is a non-issue here. We can't do anthing about it. With some
libgpg-error we introduced symbol versioning to assist the loader and to hide
internal symbols from other ELF objects.

Unaligned memory accesses are enabled on only architectures that can handle
those. The buf_xor function that you copy-pasted partially to stackoverflow
actually has alignment checks:

#if defined(i386) || defined(x86_64) || \

defined(__powerpc__) || defined(__powerpc64__) || \
(defined(__arm__) && defined(__ARM_FEATURE_UNALIGNED)) || \
defined(__aarch64__)

/* These architectures are able of unaligned memory accesses and can

  handle those fast.
*/

1. define BUFHELP_FAST_UNALIGNED_ACCESS 1 #endif ... /* Optimized function for buffer xoring */ static inline void buf_xor(void *_dst, const void *_src1, const void *_src2, size_t len) { byte *dst = _dst; const byte *src1 = _src1; const byte *src2 = _src2; uintptr_t *ldst; const uintptr_t *lsrc1, *lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS const unsigned int longmask = sizeof(uintptr_t) - 1; /* Skip fast processing if buffers are unaligned. */ if (((uintptr_t)dst | (uintptr_t)src1 | (uintptr_t)src2) & longmask) goto do_bytes; #endif ldst = (uintptr_t *)(void *)dst; lsrc1 = (const uintptr_t *)(const void *)src1; lsrc2 = (const uintptr_t *)(const void *)src2; for (; len >= sizeof(uintptr_t); len -= sizeof(uintptr_t)) *ldst++ = *lsrc1++ ^ *lsrc2++; dst = (byte *)ldst; src1 = (const byte *)lsrc1; src2 = (const byte *)lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS do_bytes: #endif /* Handle tail. */ for (; len; len--) *dst++ = *src1++ ^ *src2++; }

So, yes, we use unaligned memory accesses but only when it is known that they work.

Now, solution (with same code generation, without undefined behaviour) to this
issue is to tell the compiler that we really want to do unaligned accesses. For
that we need to change the accesses to happen through type that has proper
one-byte alignment, but generates the same code (unaligned word-size memory
accesses) on the few architectures that enable 'BUFHELP_FAST_UNALIGNED_ACCESS':

#ifdef BUFHELP_FAST_UNALIGNED_ACCESS
/* Define type with one-byte alignment on architectures with fast unaligned

  memory accesses.
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} attribute((packed, aligned(1))) bufhelp_int_t;
#else
/* Define type with default alignment for other architectures (unaligned

  accessed handled in per byte loops).
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} bufhelp_int_t;
#endif

Ofcourse, BUFHELP_FAST_UNALIGNED_ACCESS now need to be limited to compiler that
support GCC style attributes.

That is used for an experimental tool of Libgcrypt (src/gcryptrnd). It is not
clear whether this will be ported to npth or removed.

Since then we did a lot of work on Libgcrypt so that the AES-NI code is
different from May 2012. It is possible that we accidently clobbered a register
which might have been the reason for the VirtualBox failure.

I can't remember the test case, but any use of AES should have hit it. Just use
gpg where AES is the default anyway. I suggest to revert that patch an see what
happens.