Updated my system to libgcrypt-1.4.4 and as of then SVN 1.5.5 stopped working. Attempt connections to my repository fail with error: AES-128 test encryption failed. svnsync: OPTIONS of 'https://<<MySVNServer>>/blablabla': SSL negotiation failed: SSL alert received: Bad record MAC Rolling back to libgcrypt-1.4.0-r1 solved the issue If you need more info do not hesitate to ask. Best regards, Thierry
Could you test dev-libs/libgcrypt-1.4.4 + net-libs/gnutls-2.6.4?
Tried with emerge -u =net-libs/gnutls-2.6.4 and dev-libs/libgcrypt-1.4.4, problem reoccurs (even after recompile of SVN)
For me libgcrypt-1.4.4 breaks gnupg with the same error about AES-128 test. Downgraded to libgcrypt-1.4.0-r1 and everything resumed working OK. Should I open a new bug against gnupg? I guess not.
Nobody reported this bug before stabilization of dev-libs/libgcrypt-1.4.4, so it might be caused by combination of newer libgcrypt and older some other packages. (In reply to comment #1) > Could you test dev-libs/libgcrypt-1.4.4 + net-libs/gnutls-2.6.4? Also test with dev-libs/libksba-1.0.5 and dev-libs/libassuan-1.0.5.
>> Comment #3 From Daniele Boffi 2009-03-25 09:59:11 0000 >> For me libgcrypt-1.4.4 breaks gnupg with the same error about AES-128 test. % cat /etc/portage/env/dev-libs/libgcrypt CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CXXFLAGS="$CFLAGS" just downgrade your cflags to -O2
(In reply to comment #5) > just downgrade your cflags to -O2 This fixes it for me. Thanks a lot!
Some situation here, downgrade to -O2 fix it.
I can confirm this bug and also that it's fixed by CFLAGS=-O2. It also affects wpa_supplicant when connecting to an AES-encrypted WPA2 WLAN. Maybe the ebuild should filter "-O3"?
Same problems here with following programms: Pidgin-2.5.5 with USE-Flag gnutls - Error on tls connections: handshake failed Pidgin-otr-3.1.0 give allways: Selftest failed -O2 for libgcrypt-1.4.4 fixed all issues for me too.
On my amd64 system libgcrypt works when built with '-march=core2 -O3 ...'. People, who can reproduce this bug, please post the output of `emerge --info`.
Created attachment 186545 [details] emerge --info
I think it is broken in x86, and affects any package using gcrypt. I can confirm this problem with gnutls (gnutls-cli).
Created attachment 186552 [details] emerge --info
Created attachment 186559 [details] emerge --info Fails make check (details to follow)
Created attachment 186566 [details] make check Fails "make check". The segfault (/bin/sh: line 4: 27025 Segmentation fault ${dir}$tst) is somewhat worrying. Succeeds with -O2. GCC bug?
Could you test libgcrypt built with =sys-devel/gcc-4.3*?
I used sys-devel/gcc-4.3.3-r2 to build dev-libs/libgcrypt-1.4.4 with -O3 on x86. It works fine.
(In reply to comment #17) > I used sys-devel/gcc-4.3.3-r2 to build dev-libs/libgcrypt-1.4.4 with -O3 on > x86. It works fine. Maybe gcc-4.1.2 produces invalid code during compilation of libgcrypt. CC-ing toolchain for advice.
(In reply to comment #17) > I used sys-devel/gcc-4.3.3-r2 to build dev-libs/libgcrypt-1.4.4 with -O3 on > x86. It works fine. > Did you test it w/ 4.3.2 too (b/c that version goes stable soon)
(In reply to comment #19) > Did you test it w/ 4.3.2 too (b/c that version goes stable soon) Retried with gcc-4.3.2-r3, it also works.
(In reply to comment #16) > Could you test libgcrypt built with =sys-devel/gcc-4.3*? > I tested it with gcc-4.3.3-r2 and gcc-4.3.2-r3 and with this two versions there are no problems with -O3 flag on libgcrypt. Perhaps gcc bug?
i would add something to the ebuild along the lines of: [[ $(tc-arch) == x86 && $(gcc-version) == 4.1 ]] && replace-flags -O3 -O2 #263589 we add flag filters for current stable gcc versions ... while we are looking at stabilizing 4.3.2 soonish, this flag filter cant hurt may want to revbump as well ...
Created attachment 186985 [details] emerge --info switching to "-02" and emerge libgcrypt work here too.
Created attachment 187153 [details] emerge ---info also breaks vpnc when connecting to AES encrypted VPN switching to -O2 on libgcrypt and recompiling vpnc fixes issue
Fixed.
This problem is specifically caused by '-finline-functions'. I'm running x86_64 with CFLAGS set to '-O2 -march=nocona -finline-functions -mmmx -msse -msse2 -msse3 -mfpmath=sse -w -pipe' I removed '-finline-functions' and rebuilt 'libgcrypt-1.4.4' to fix the problem.
Problem still exists in the latest ebuild for libgcrypt 1.4.4 I am running an amd64 with CFLAGS="-march=nocona -O3 -pipe -fomit-frame-pointer" I do NOT use -finline-functions and I still have the problem. I use gcc 4.3.2-r3 p1.6 The problem dissapears if I use -O2. The current ebuild only fixes/solves the problem for x86 architecture!!!
I can't reproduce this bug on amd64.
I can. All the attempts to decrypt a message fail with this error: "Selftest failed"
this is NOT RESOLVED FIXED for x86_64 (gcc 4.3) in 1.4.4's ebuild
This bug is also not fixed for me, on amd64. When starting pidgin: AES-128 test encryption failed. I guess that following line in the ebuild: [[ $(tc-arch) == x86 && $(gcc-version) == 4.1 ]] && replace-flags -O3 -O2 should also include amd64.
Created attachment 205672 [details, diff] libgcrypt-1.4.4-r1 ebuild patch
Created attachment 205674 [details] emerge --info
The patched ebuild works for me.
Hi mephinet, I think this will solve the problem for amd64 AND gcc 4.1 But I have this problem on amd64 using gcc 4.3 So, shouldn't you just test for amd64 in the ebuild? chris (In reply to comment #31) > This bug is also not fixed for me, on amd64. > When starting pidgin: > AES-128 test encryption failed. > I guess that following line in the ebuild: > [[ $(tc-arch) == x86 && $(gcc-version) == 4.1 ]] && replace-flags -O3 > -O2 > should also include amd64. >
(In reply to comment #35) > But I have this problem on amd64 using gcc 4.3 I haven't test this on gcc 4.3 - but if the problem occurs there, too, sure, this should be filtered as well...
(In reply to comment #35) The problem doesn't occur for me on amd64 with GCC 4.3.
-O3 failes too on gcc4.3.3 / x86(32bit). -O2 works. will this be fixed in the ebuild?
