2.1.1 has been released.

Okay, fixed with commit 5cb6df8.

That is... just far too obvious for words. *facepalm*

Okay, this works nicely for my needs. Wrapper scripts can turn it into a
site-wide policy.

You need to create a redirection file for ssh too:

Set contents of ~/.gnupg/S.gpg-agent.ssh to:
%Assuan%
socket=${HOME}/.gnupg/S.gpg-agent.ssh-${HOSTNAME}

BTW, I just commtied the missing chnages to dirmngr and scdaemon.

For easier debugging you set a log file for gpg-agent or even better set that
log file to a socket in gpg-agent.conf
log-file socket:////home/foo/.gnupg/S.log
and the run
watchgnupg --time-only --force /home/foo/.gnupg/S.log
in another xterm.

Does this now also work for you?

Yes. Thank you.

Please do not use the title to describe an error. Here is the description you gave:

gpg: keyblock resource `C:/Program\secring.gpg': file open error gpg: keyblock
resource `C:/Program\pubring.gpg': file open error usage: gpg [options] [filename]

Please add more specific information. What Web application, which gpg4win
versions, etc. You may also want to ask for help on one of the maling lists.

This should be fixed in 2.2.3 (Which will be released soon)

Gpgtar now handles all filenames using the windows 8bit charset. It still does
not support full unicode filenames. For this the fix would have been larger but
at least kleopatra now reacts to gpgtar errors so when you include a File that
can not be handled it will show an error and mention the file that was problematic.

The generated header file is, as expected, identical to the one we use
when cross-compling (modulo that we put both versions into one file).
Thus I came up with a simpler solution (see below). I'll commit it soon and a
release will also follow today.

+force_use_syscfg=no
if test "$have_w32_system" = yes; then

AC_DEFINE(HAVE_W32_SYSTEM,1,[Defined if we run on a W32 API based system])
if test "$have_w64_system" = yes; then

@@ -461,11 +462,17 @@ if test "$have_w32_system" = yes; then

  AC_DEFINE(HAVE_W32CE_SYSTEM,1,[Defined if we run on WindowsCE])
  GPG_ERROR_CONFIG_ISUBDIRAFTER="gpg-extra"
fi

+ force_use_syscfg=yes
fi
+if test x$cross_compiling = xyes; then
+ force_use_syscfg=yes
+fi
+
AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)
AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes)
AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes)
AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
+AM_CONDITIONAL(FORCE_USE_SYSCFG, test x$force_use_syscfg = xyes)

AC_DEFINE_UNQUOTED(HOST_TRIPLET_STRING, "$host", [The host triplet])

Modified src/Makefile.am
diff --git a/src/Makefile.am b/src/Makefile.am
index 65f8513..efc5970 100644

• a/src/Makefile.am

+++ b/src/Makefile.am
@@ -262,9 +262,9 @@ parts_of_gpg_error_h = \

 	w32ce-add.h      	\
 	$(lock_obj_pub)

• If we are cross-compiling we better make sure that no stale native
• lock include file will be found by mkheader.

-if CROSS_COMPILING
+# If we are cross-compiling or building on Windows we better make sure
+# that no stale native lock include file will be found by mkheader.
+if FORCE_USE_SYSCFG
pre_mkheader_cmds = -rm lock-obj-pub.native.h 2>/dev/null

Interesting.

Use "=c" does now work with commit bc8583f2.

What "that" are you referring to? In all the versions of GPG I've tried, 1.4,
2.0, 2.1 including this current one in git, it is possible to create a
Certify-only master key by toggling off "Sign" (and "Encrypt", for RSA).

I am saying this should be possible for the "=flags" syntax as well. I would be
happy with either "=" or "=c". The latter is clearer, but inconsistent with the
existing syntax in git which ignores "c" completely, and just forces Certify on
for the master key and off for the subkey.

$ gpg2 --full-gen-key --expert
[..]
Please select what kind of key you want:
[..]
Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
[..]
Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt
[..]
Your selection? e

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify
[..]
Your selection? q

[..]
GnuPG needs to construct a user ID to identify your key.

Real name: Testing
Email address: lol@test
Comment:
[..]

gpg: key 0822FCC2D521C45C marked as ultimately trusted
public and secret key created and signed.
[..]

$ gpg2 --edit-key lol@test
[..]

Secret key is available.

pub rsa1024/0822FCC2D521C45C

created: 2014-10-02  expires: never       usage: C   
trust: ultimate      validity: ultimate

[ultimate] (1). Testing <lol@test>

gpg>

That was never possible.

Hi, this does not currently allow me to set the master key to Certify only. If I
enter "=" or "=c" it just ignores me and goes back to the default value. Looking
at commit 7ff4ea21 I'm not sure why this is the case, since current should be 0
at the end. Setting "=a" gives me a CA-use master key as expected.

It would be good to note in the help text that a master key always has the C
flag, and a subkey does not (as far as the "=" syntax is currently implemented).

Thank you! This solution sounds good, I will test it this weekend.

Done for 2.1 and 2.0.

Use "=esa" to set all capabilities. Enter '?' for help ;-).

What I implemented now is a simple one item cache for the last used passphrase.
This works in all standard cases. Trying more keys is not possible because
unprotecting a key introduces a delay to help against dictionary attacks.

See my comment on and fix on the mailing lst.

Unfortunately, version 1.15 breaks on the current version of OS X (10.9):

mv -f .deps/libgpg_error_la-posix-thread.Tpo .deps/libgpg_error_la-posix-thread.Plo
estream.c:3501:1: error: conflicting types for '_gpgrt_fseeko'
_gpgrt_fseeko (estream_t stream, gpgrt_off_t offset, int whence)
^
./gpgrt-int.h:108:5: note: previous declaration is here
int _gpgrt_fseeko (gpgrt_stream_t stream, off_t offset, int whence);

^

estream.c:3527:1: error: conflicting types for '_gpgrt_ftello'
_gpgrt_ftello (estream_t stream)
^
./gpgrt-int.h:110:7: note: previous declaration is here
off_t _gpgrt_ftello (gpgrt_stream_t stream);

^

2 errors generated.
make[3]: * [libgpg_error_la-estream.lo] Error 1
make[3]: * Waiting for unfinished jobs....
mv -f .deps/libgpg_error_la-estream-printf.Tpo .deps/libgpg_error_la-estream-printf.Plo
make[3]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15/src'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15/src'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/opt/local/var/macports/build/_Users_marius_Development_MacPorts_ports_devel_libgpg-
error/libgpg-error/work/libgpg-error-1.15'
make: *** [all] Error 2

To use --multifile with files on the command line. Such a use will suddenly
break. This is the same as using grep on a large number of files - only rookies
do that.

Not sure what you mean by "It is not useful for that purpose" what do you mean
by "It" and "that" in this context.

With regard to complaints there are reports about this that have been active
nearly all the time since this was broken by 2.2.0:
https://wald.intevation.org/forum/message.php?msg_id=2569&group_id=11

This thread triggered your initial opening of this issue.

I agree that wildcard / multifile it is not very important. But I think we
should fix it as it is a small annoyance and it worked with gpg 2.1.0. That it
stopped working was due to our switch to mingw-w64 and not due to a decision
made by us to disable this. So I would see this as a Bug.

Some more threads about this:
https://wald.intevation.org/forum/forum.php?thread_id=1119&forum_id=21&group_id=11
https://wald.intevation.org/forum/message.php?msg_id=3404

P.S.
Yes I dislike the message boards too but they are surprisingly active.

It is not useful for that purpose. This is probably the reason why we received
no complaints about it unless someone uses --multifile with filenames. It is
almost always wrong to do this.

I disagree, all builtin windows tools do globbing so you expect it on the
command line. And as this is default for software that is built with visual
studio and with some versions of mingw it is more likely to see a software that
supports globbing then not.

With regards to quoting problems. I think that users would prefer some problems
instead of just "no". There is no xargs equivalent in Windows by default and so
you have to fall back to really ugly batch scripts that do this in for loops.

Yes one could argue that those users should use a "real shell" on a "real
system" ;-)

Well, it's part of 2.2.2 now, lets see if we get some feedback on this and maybe
for the next release we can revisit the question again if we should enable this
or not.

It would be rather surprising if just one tool does globbing on Windows but all
the otehrs don't do it. It may actually lead to bugs due to broken quoting in
mingw. I recall than many years ago we had a lot of problems with the ever
changing quoting in the globbing implementation.

In any case using globbing with --multifile is not a good idea at all. There is
always a limit on this and thus the proper way of handling this is to use xargs
or whatever the counterpart is on Windows.

Tested this myself again. And I feel comfortable that this is fixed. Still I do
not know why this works now.

Werner can you take a look at the patch I've added for this:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=patches/gnupg2-2.0.26/0001-Enable-wildcard-expansion-with-mingw-w64.patch;h=6c5b9f8b0794cf32ab909c0a340f81377dc3d42f;hb=HEAD

Is this something you would consider including in some form in gnupg or should I
move the patch into the generic gnupg patch directory?

Please try the attached patch

Not sure but everything seems to be working in the 2.2.2-beta relase.

Hi Jon,
can you check this please with the current gpg4win-2.2.2 beta? I've fixed some
object resolution bugs there when Sender / Recipient addresses were not SMTP only.

Thanks

Fixed with commit 45e3b81. Will go in 1.4.19, release dates not yet known.

Ok using the same compiler I've used a year ago I also get the same result I got
a year ago (phew I thought i screwed up the test).

But with the patch this should just work once we change the used mingw-version.
I could not find a bugreport or some other information where and when this is fixed.

Tested the patch with 1.4.4 on Windows against
vm-keyserver.spline.inf.fu-berlin.de which did not work previously.

Patch is also included in gpg4win now.

Thanks!

Thanks for that good description. Fixes pushed to master and 1.6. I can't test
it, though.

I won't call that leaking memory.

With your fix it no longer crashes. But you are leaking memory in case
default_homedir returns allocated memory from read_w32_registry_string or
standard_homedir with a successful call to w32_shgetfolderpath.

As the result should be cached in the static variable this is probably not an
issue..

I just pushed a fix.

The problem with gpgme is that we need to stop the Explorer if we want to update
or uninstall gpgme. Given tha we can't use gpgex with the portable version
anyway, I think it is better to keep the existing code and don't switch to gpgme.

This has recently been discussed at gnupg-devel. We have patches ready for 1.4

Hello Yutaka,

With current 2.0 branch of git repository, I believe that Vega-Alpha works fine.
Please confirm.

Fixed for master.

Fixed for 2.0. But take care: The code now also uses the fixed-list-mode which
is the default in --list-keys for ages:

pub:-:1024:17:4713D527ECE16009:1118095577:::-:
fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009:
uid:::::::::George Hacker <georgeh@axian.com>:
uid:::::::::George Hacker <ghacker@axian.com>:
uid:::::::::George Hacker (GLS) <ghacker@redhat.com>:
uat:::::::::1 2493:
sub:-:1024:16:0D94CF6C0C8C2F1B:1118095578::::

It is not the keygrip but the authority key identifier based lookup
which fails. Quite obvious if they do that stupid re-issuing. The
problem with dirmngr is only a side-effect of gpg not using the proper
certificate form the chain. Though, the question is which is the
proper certificate? They are both correct. I solved that my looking
for all matching certificates and using the latest one. That should
match reality better. Below is a log using a certificate store with
both DFN certificates. I have not done any Dirmngr tests, though.

The old certificate:

    ID: 0xFFFFFFFFA3EFE945
   S/N: 00C7
Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust

Center/O=Deutsche Telekom AG/C=DE

  Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE
 validity: 2006-12-19 10:29:00 through 2019-06-30 23:59:00
 key type: 2048 bit RSA
key usage: certSign crlSign

chain length: 2

  fingerprint: F0:28:8F:DA:C6:3A:F7:9A:31:9A:E9:72:F3:95:09:0E:A3:EF:E9:45

The re-issued one:

    ID: 0x55715DB8
   S/N: 0089901115583E879B
Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust

Center/O=Deutsche Telekom AG/C=DE

  Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE
 validity: 2014-02-11 13:11:45 through 2019-07-09 23:59:00
 key type: 2048 bit RSA
key usage: certSign crlSign

chain length: 2

  fingerprint: 2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8

Use gpgsm --dump-cert to see the other info. By deleting one or the
other certificate and importing them in a different order, it is
possible to verify that the latest certificate is use.

$ echo hallo | ~/b/gnupg/sm/gpgsm -ea --disable-crl-checks --debug 1 -r Schnarre
gpgsm: used in a production environment or with production keys!
gpgsm: enabled debug flags: x509
gpgsm: DBG: BEGIN Certificate 'target':
gpgsm: DBG: serial: 13F7C661A329F4
gpgsm: DBG: notBefore: 2012-06-13 08:01:21
gpgsm: DBG: notAfter: 2015-06-13 08:01:21
gpgsm: DBG: issuer:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#736162696E652E6C657574686575737365722D7363686E617272656E6265726765724062756E6465737461672E6465,CN=Sabine
Leutheusser-Schnarrenberger,OU=MdB,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
73:99:B8:58:93:E5:F8:E0:D7:7C:BE:7F:D8:4C:14:86:78:A1:E8:03
gpgsm: DBG: END Certificate
gpgsm: failed to open '/home/wk/.gnupg/policies.txt': No such file or directory
gpgsm: note: non-critical certificate policy not allowed
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0D688CAF
gpgsm: DBG: notBefore: 2008-12-17 14:39:27
gpgsm: DBG: notAfter: 2019-06-30 00:00:00
gpgsm: DBG: issuer: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
0A:0D:87:72:EE:E7:B9:47:AE:A7:FC:58:C5:47:90:7F:75:F9:50:62
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0089901115583E879B
gpgsm: DBG: notBefore: 2014-02-11 13:11:45
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.11
gpgsm: DBG: SHA1 Fingerprint:
2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: intermediate certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 26
gpgsm: DBG: notBefore: 1999-07-09 12:11:00
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: root certificate is good
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: encrypted data created

Fixed in master (i.e. 2.1)

Fixed with commit 2bb2618 for master. Will go into 1.5.0.
Thanks.

Also applied to master.

Done and 1.6.1 released

Thanks. I backport it tomorrow.