Patch breaks the tests.

I think that's fixed now.

Fixed in ebc65ff45 by always saving to standard path.

No, it's not. It still misses "-O" entirely.

It's solved!

@fogine , I'm afraid your comment is related to this bug particular report of T1983: gpg2 prefers missing secret key to available key on card.
And your problem cannot be replicated by my environment with 2.1.22.
If you still have the issue with 2.1.22, please open new ticket.

I think that this issue is fixed in 2.1, which use KS_FETCH instead of KS_GET with fingerprint.
Please test with 2.1.
We don't change 2.0.

Fixed in 2.1.22.

gpg (GnuPG) 2.1.21
libgcrypt 1.7.8

debug dns

log-file whateveryouwant

You're right, stat() works correctly. I created a small tool that implements the same logic. For some reason dirmngr is still not able to find the DNS server after suspend/resume in combination with changed locations. I still get "no route to host" errors.

According to POSIX stat(2) follows a symlink and thus /etc/resolv.conf is the right name to use. (To stat /etc/resolv.conf itself lstat(2) would need to be used. ). I just checked the macOS man page and it says nothing to the contrary.

getting same error with 1.7 version also.

Could you please help me on this, any fix do you have for this kind of issue.

not able to apply given patch in my unix box, please find the below output.

GnuPG 2.1.22 in Homebrew is out: https://github.com/Homebrew/homebrew-core/commit/39a392ffd6ac20a36ea8a4aec5c4dc5febcfc1d6
Please check it out.

I've found that I can get the test to succeed if I drop --disable-scdaemon from my configure flags. I'm far from qualified to diagnose this, but I suspect that the tests have a bug in which they still try to test the scdaemon despite the presence of --disable-scdaemon in the configure flags.

Could you please provide me the dyñamic library path to set my profile Solaris 10 command

On Sat, 29 Jul 2017 15:12, noreply@dev.gnupg.org said:

could you please guide me order to install below libraries and I will update you once I apply that patch .

Also could you please guide me the order to install these libraries to solaris box.
I am installing as below order:
npth-1.5
libgpg-error-1.27.tar
libgcrypt-1.8.0.tar
libassuan-2.4.3.tar
libksba-1.3.5.tar
gnupg-2.1.21.tar

The maximum passphrase length is defined in agent.h:

You can apply this patch by first navigating to libgcrypt-1.8 path and then giving following command (you need 'patch' tool to be installed):

please guide me how to add this patch in solaris 10 os version

the first time, I just did : ./configure
then, after seing it was not working, I tried : ./configure --prefix=/usr && make

In libgcrypt, _gcry_md_extract has different return type in gcrypt-int.h than in md.c. Does attached patch solve the problem?

URL | name ]]URL | name ]]Hi Werner,

Please provide information on how you build this. That is invocation of configure and make and best attsch the created config.log.

Sure it won't apply because it is part of 2.1.22. ;-)

Your build system is not correctly set up. How did did you invoke configure?

The "Suppress error for card availability check" (https://dev.gnupg.org/rGa8dd96826f8484c0ae93c954035b95c2a75c80f2) won't cleanly apply to 2.1.22, so my build was without it.

why should it wait for the timeout in the pselect call? shouldn't it be able to respond immediately to the final connection closing?

Yes, that commit was in 2010, but it was on the 2.1 branch, which never saw wide distribution until this year, which means that there are test suites (like the one mentioned in request-tracker) which simply fail hard when used against gpg 2.1. Is there explicit guidance that the GnuPG project wants to give to downstreams like request-tracker?

To remain compatible with PGP6 we are limited to ustar. If you want to support other archive types, archive first and then encrypt/sign the archive.

where i can found the Test Directory

Normally this error message can only come from gpgsm or dirmngr in case a certificate is listed that does have unsupported (unknown) critical extensions. Are you using X.509? What certificates do you have imported? You should be able to see the error and more information on the command line with "gpgsm -kv" and maybe some more options...

This is a question on how to install and use gpgme. Please direct this to the gnupg-devel mailing list.

I'd suggest that you install the missing nPth library. The configure message is pretty clear about it.
The warnings are irrelevant.

We can't do anything about thisfor the oldversions. You may use libgcrypt 1.8.0 which has a faster entropy collector and also allows to map /dev/random to /dev/urandom using the new /etc/gcrypt/random.conf

Sorry to have overlooked your report initially.
We fixed some bugs related to this. Can you please try with the latest Beta from https://files.gpg4win.org/Beta/current/

Outlook 2003 is no longer maintained.

Fixed in 94eea0ed2c8b47cb0fe02b22cbe668705a5fe0d0

.

gpg 1.4 only gets important updates.

This is solved easily by using "--yes", which sets the force flag on the DELETE_KEY operation. This prevents gpg-agent from doing a confirmation.

Here is what Vinay Sajip wrote:

Thanks, fixed in 01c68a6a.

According to the link above, the reason we need entropy on import is the KEYWRAP between gpg and gpg-agent. The reason we are stalling is that we use getrandom() and the urandom pool is apparently not initialized on that system.

The beta is not released, but maybe Andre can make use of that info.

It takes a couple of seconds for dirmngr to terminate after closing the last connection, maybe due to the timeout in the pselect call. Apart from that, it works as expected.

Well, the 16 byte fingerprint is used for MD5 (old v3 keys). Those aren't supported by default anymore, but the comment indicates that discerning existing entries is difficult.

What catches my eye is that emergency_cleanup() is not guarded from being invoked twice in the way that got_fatal_signal() is.

Besides -v, --status-fd 2 (for example) also shows useful information, as usual.

You get more information with -v. Because a key can have multiple subkeys, this is not so easy to fix, because at the point that we decide that we can't build the signature we don't have all the information on potential key candidates anymore.

We now strip trailing slashes (and backslashes on Windows) when setting the home directory with --homedir and when retrieving it from GNUPGHOME.

I would say this is okay now. We switch to the Windows system directory which is unlikely to have non-ascii characters. If we ever need to change this, this can now be done in gnupg-chdir and the new gnupg_daemon_rootdir functions.

This needs to be changed. See the comments for the commit.

The last time GOOD_PASSPHRASE was emitted was in 67934a8c1 (parent of 21b0a955) in 2010. I think that's just water down the river at this point.

A decision must be made what the desired behaviour should be.

Ah, yes, this can happen, see T2313. With --batch, this can be avoided, and I added the NEED_PASSPHRASE with 872137b59.

@marcus From my memory, importing private keys with passwords requires passphrase. Is this not a case in recent versions? What when you have some private keys in keyring and you import more private keys? Isn't the access to private keyring password protected in GnuPG 2.1 as I thought?

This works in recent 2.1.x versions, so let's close this here. 2.0.x is going EOL soon and won't get non-critical changes.

Can somebody test 78ebc6260 under Windows? I think this would fix it.

Werner implemented --output in a8363b7d0bcc77b55226d5fe8f972214c968ddc3.

Thanks, I fixed this in d8e46f106 for export-secret-keys. I am not sure how/when import asks for a passphrase. Please clarify if that is still an issue and reopen the report (or create a new one).

We can't reproduce this with recent versions and would need more information.

The diff was commited. A general review of the ldap fetching on Windows is still pending but I think this can be resolved for now and we revisit this topic when we see new problems.

The fixed sed expression still does not work correctly; it misses the plain "-O" form of the option. As per gcc docs, -O is the same as -O1, and clang accepts it (and the build falls over with it) even though it does not document it at all.