A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 29 2018
Oct 26 2018
Oct 25 2018
It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.
Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.
OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.
Oct 24 2018
May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.
Sep 4 2018
Closing.
May 17 2018
Apr 13 2018
Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.
Jan 24 2018
Are you sure that you are runtime linking to the same libgpg-error version you used for the build?
Dec 8 2017
There is now also Gpg4win-3.0.2 with that gnupg version available.
I've been running gnupg-w32-2.2.3_20171207.exe for about as long as it's been available and no hanging whatsoever. Thanks a lot!
Dec 7 2017
W/o a special tag in the commit there seems to be no way to mark a patch as applied.
All commited. I created a new installer gnupg-w32-2.2.3_20171207.exe which comes with the new libassuan 2.5.1 and the two required patches for gnupg.
I pushed this change with the addition of a doc entry and to protect against a not yet initialized socket interface.
Dec 6 2017
Applied to libassuan master.
Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth
For better reproducibility of hang, this is more better:
It's a patch to libassuan. The patch to gpg-agent is not the exact one. libassuan patch is the exact one.
I'm doing the test. I'm currently waiting on a hang with the test change applied.
If you can get the developers to make a try-build that is built securely then I'd guess most of us would be happy to try it. Not all of us have a build system for gpg.
To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:
And then, please confirm that rG1524ba9656f0: agent: Set assuan system hooks before call of assuan_sock_init. can fix this, even with the patch for testing.
Dec 5 2017
Alright, I need to weight in with something that may possibly be influencing the failure of the December-01-2017 build to operate correctly over here; since this issue is related to sockets, and I have set up a rather unusual security apparatus on my system ("unusual" as far as computers regularly running GPG are concerned, and that only to my personal experience, meaning no reliable statistics or anything), I think it's worth mentioning that my firewall (Sygate Personal Firewall Pro) is configured to be very restrictive and that virtually anything that utilizes tcp or udp is being routed through socks5 via ProxyCap, and that neither application is currently allowing GPG to have access to any address but localhost (there's a reason for this and has got nothing to do with GPG itself, but that's part of a different discussion).
Dec 2 2017
:-(
Ok here's an update.
Superb! Testing gnupg-2.2.3_171201.exe as I type, and it's already working past the time it would normally cease to respond :)
Dec 1 2017
A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.
The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".
Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS
Yeah, that looks correct. Good catch. The bug exhibits itself when gpg-agent checks its own socket. In this case gpg-agent is both, client and server, and due to our userland multi-threading we get blocked. The suspend/resume things makes the deadlock more likely. Note that we have the same problem on Unix.
Nov 30 2017
Oct 26 2017
Thanks for the list
Here is the list:
- libgcrypt
- libassuan
- ntbtls
- gpgme : autogen.sh is ready
- npth
Sep 6 2017
Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.
I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.
It will be in the next release (2.4.4).
Thanks for reporting.
The description of this bug report is not correct.
_POSIX_C_SOURCE should *not* be defined to use INADDR_LOOPBACK for the system.
Sep 5 2017
Jul 27 2017
Jul 26 2017
Jul 6 2017
We don't support pkg-config, because it is not POSIX. See https://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028474.html for discussion.
Jun 23 2017
Thanks for testing.
Confirmed that it now compiles ok on Fedora, thanks.
Thanks for the reminder. Fixed.
Note that LIBASSUAN_LIBS is not needed because it is already part of t_common_ldadd.
I'm still hitting this on Fedora. The patch is simple and was posted on the mailing list but apparently not incorporated into git:
Mar 30 2017
Mar 1 2017
This happens on at least PPC Mac OS X 10.4.11, Tiger. Compiler is by default Apple's
version of GCC 4.2. The error is reported as this:
libtool: compile: /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I..
-I.. -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith -MT
libassuan_la-assuan-socket.lo -MD -MP -MF .deps/libassuan_la-assuan-
socket.Tpo -c assuan-socket.c -fno-common -DPIC -o .libs/libassuan_la-
assuan-socket.o
assuan-socket.c: In function 'socks5_connect':
assuan-socket.c:732: error: 'INADDR_LOOPBACK' undeclared (first use in
this function)
assuan-socket.c:732: error: (Each undeclared identifier is reported only
once
assuan-socket.c:732: error: for each function it appears in.)
make[3]: * [libassuan_la-assuan-socket.lo] Error 1
make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
make: * [all] Error 2
make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3"
&& /usr/bin/make -w all
Cause is that the declaration of 'INADDR_LOOPBACK' is hidden behind some guards. The
two external links document the situation, they also offer patches, either the attached
one or this addition for src/assuan-socket.c:
//fix missing define in MacOSX 10.4 Tiger
#ifndef INADDR_LOOPBACK
#define INADDR_LOOPBACK (u_int32_t)0x7f000001
#endif
In ten days I'll be at home again with my Apple PowerBook G4 and might have time to
check the situation in Mac OS X 10.5, Leopard.
See T2910.
Nov 2 2016
I'm closing this bug due to inactivity. Feel free to reopen it with more
information.
Aug 24 2016
I have seen that but pretty pelase describe it here so that we can also work
with email.
Detail info in https://trac.macports.org/ticket/51708
OS: PPC Tiger, Mac OS X 10.4.11
The build process is automated by macport.
Aug 23 2016
Please describe exactly how you build Libassuan. Compiler, OS etc, error message.
Aug 2 2016
Jul 14 2016
2.4.3 has been released and I assume that this works now. Feel free to re-open
if it is not the case.
Jul 13 2016
Patch applied with commit c52829e for 2.4.3.
Thanks.
Had you a chance to run the suggested test?
Thanks. Changed with commit 678f606 for 2.4.3
Apr 22 2016
Thanks for the output. That indeed confirms my suspicion. Let's read it together:
[...]
libassuan.so.0 =>
/home/ann/gnupg-2.1.11/libassuan-2.4.2/src/.libs/libassuan.so.0 (0x002e4000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0x0066d000)
ldd says which library is used to satisfy a dependency at load time. You see
here that for libassuan.so.0 your newly built library is used. That is good.
However, for libgpg-error.so.0 the library from your system is used which does
not have gpgrt_asprintf, hence the error message in your first log.
What you need to do is to make sure the runtime linker finds your gpg-error
library. Since this kind of problem will occur for each library, it is best to
install all the libraries you built to a common prefix, say /home/ann/local or
/usr/local by specifying --prefix=/my/prefix at configure time, and then to set
LD_LIBRARY_PATH to /my/prefix/lib and include /my/prefix/bin in PATH, so that
gpg-error-config and libassuan-config and co are found at compile time. Feel
free to ask questions if you get stuck.
(If you don't want to do all this by hand, and merely want a working modern
GnuPG, you can also use the 'speedo' framework. See the README in the GnuPG
repository for some hints.)