Did you notice the

the scripts print sicne version 2.0.13 ;-)

Fixed with commit e957b9b for 2.0 - will be backported to 1.4 soon.

Thanks.

The trustdb is only recomputed if required. It is not done by--edit-key thus
the info there might me incorrect. Run "gpg --check-trustdb" to force an update.
Please take such discussions to a ML - it is not appropriate for a bug tracker.

No, there is no third field - check the code.

Merging of secret keys has never been not supported. GnuPG 2.1 has a
architecture redesign which supports secret key merging. There won't be any
backport.

@werner:

See this example where I change the trust value to "2" as the program currently
enables (with one field):

$ echo "ABCDABCD....ABCD:3:" | gpg --import-ownertrust
gpg: changing ownertrust from 6 to 3
$ gpg --edit-key "Dor"
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

gpg: checking the trustdb
gpg: no ultimately trusted keys found
pub <key_size>R/<key_id> created: 2013-09-25 expires: never usage: SC

trust: never         validity: unknown

sub <key_size>R/<key_id> created: 2013-09-25 expires: never usage: E
[ unknown] (1). <Full name> (<nickname>) <email@addr.com>

---------------

There's a string written "unknown" - why is that? Maybe something's missing?

See another example when I set the trust value to Ultimate with two fields:

$ echo "ABCDABCD....ABCD:6:6" | gpg --import-ownertrust
gpg: changing ownertrust from 3 to 6
$ gpg --edit-key "Dor"
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub <key_size>R/<key_id> created: 2013-09-25 expires: never usage: SC

trust: ultimate      validity: ultimate

sub <key_size>R/<key_id> created: 2013-09-25 expires: never usage: E
[ultimate] (1). <Full name> (<nickname>) <email@addr.com>

---------------

Now we can see the string "ultimate" instead of "unknown".

This is why I think there are 2 fields in the --export-ownertrust command.

I am not sure how you get the idea that there are 3 fields. The ownertrust is
merely the fingerprint of the primary key and the ownertrust value.

So, we can try to use it again by default. Thanks for testing.

D179: 387_gpgkeys_curl.patch

Removing the dup() call also seems to fix the unresolved Mac issue with gpg2
2.0.21 and gpgme 1.4.3 compiled with --enable-fd-passing

Ah well, the Spansih versions have been dropped. The Howtos are anyway somewhat
outdated.

I took copies of the MiniHowto from archive.org and put them direct under GnuPG.org.

Duplicate of T1535

That is a GnuPG. See T1535.
I just pushed a fix to the 2.0 branch.

That is a very good analysis. Looking at the history of the code shows:

    2009-11-10  Marcus Brinkmann  <marcus@g10code.de>
    
    	* server.c (cmd_getauditlog): Don't dup FD for es_fdopen_nc as
    	this leaks the FD here.

that is in master. I cherry picked it and pushed it to 2.0. Many thanks.

I notice that there are other users with the crash problem who are using a non-
standard location for the home directory, and using GNUPGHOME in the Environment
Variables to point to the homedir.

As an experiment, I tested moving the GNUPGHOME pointer from the "User
variables" to the "System Variables" section of the configuration screen. It
makes NO difference - gpgex crashes Windows 7 Explorer in both scenarios,
although Kleopatra functions as expected in both scenarios.

For diagnostic reasons: could you try with Kleopatra as well?

Maybe this is relevant:
I only installed gpg, gpgEX and GPA from the GPG4Win package.

Using gpg.exe on the command line works perfect.
I can en- and decrypt files and sign and whatnot.
Only gpgEX is affected.

The crash happen regardless of what I did before. Usually I use Q-Dir as file
browser. When I trigger a gpgex action via context menu in one Q-Dir OR Windows
Explorer the program (the one I used) crashes.

I set GNUPGHOME as a user variable via Windows' Extended System Settings.

I followed Bernhard's suggestion and attached the GpgEX debug log.

Please provide a proper bug report so that we are able to replicate this. For
example, how did you set GNUGHOME, what process have been started before that
etc. A complete run trough on how to exhibit the bug would be a appreciated.

This is not a worth a bug report. If you want to discuss this topic, please use
the gnupg-users mailing list. We can't answer indivdual questions by means of a
bug tracker.

Thanks for asking again, I did not remember that GPGex was missing from the
compendium.

It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html

Actually, I can't.
The link you provided leads to a site with some general infos.
There is another link into the compendium with infos about
some GPG4Win components but not a single word on gpgex.

So HOW do I provide some more diagnostic output?

Hi Henning,
thanks for your feedback on Gpg4win and of trying the new Gpgex.

Can you help us further by trying to get some more diagnostic output?
See the link in the last section of http://gpg4win.org/reporting-bugs.html

Best,
Bernhard

works with Gpg4win 2.2.0. But there is a failure after decrypting folder with
umlauts: see gpg4win wald issue #6451
(https://wald.intevation.org/tracker/index.php?func=detail&aid=6451&group_id=11&atid=126)

Forgot to mention, throw-keyids is a workaround by not sending the key ids but
it confuses many people when trying to decrypt those messages. So a different
approach is necessary

This is a bug tracker and not help list. Please send your questions to
gnupg-users@gnupg.org

Issue 1530 notes that gpgex crashed Explorer (Win7-64bit) when the Environment
Variable for GNUPGHOME is not at the default setting.

I can confirm this! My configuration is customized, and I am not using the
default path.

D178: 385_libgcrypt-rndlinux.patch

I've done more testing, If the gnupg folder is not moved from its default
location gpgex.dll works in v 2.2.0.

The gpgex.dll problem occurs in version 2.2.0 when the user's GNUPGHOME
environment variable has been set to a non-default location (not the user's
default \AppData\Roaming\gnupg)

Kleopatra works fine but for some reason gpgex doesn't work. It produces an
error "Cannot connect to the GnuPG interface (Kleopatra): IPC Connect call failed"

D169: 384_verify_doc.patch

I'm reading in your response that you're not eager to change the behaviour of
--verify in this regard, right?

If that's the case, perhaps you can consider this patch to add a note to the
documentation, making it clear what is expected when using --verify on inline
signed files with auxiliary data. Afterall, we've seen several places where
--verify was used insecurely in the wild, so some warning may be in order.

Oh sorry, never mind. Apologize for the noise. I accidentally looked at the
relevant file in 2.0.20 and thought it hadn't been fixed yet. Sheesh.