Better screenshot of the fallback showing a real call by gpg-agent instead of a
"getpin"

Neal: I've commited this with: 71b51e02cf20174ba7144765e985f7e889eaa429

The Make passphrase visible is in the tab order after the line edit. I don't
know how to best change this in GTK and the "Save passphrace using libsecret"
button would have the same problem.

I don't think it's a real problem though as you would have to tab + space to
make the password visible. Tab + Enter would just accept the dialog.

If you think this ok you can set this issue to resolved. You can also change the
setting you mentioned in T2139 (neal on Dec 07 2015, 10:09 AM / Roundup) . I don't know how. :-)

We might want to change the strings in gpg-agent though. I would prefer: "Show
passphrase" instead of "Make passphrase visible".

Fallback variant. (Qt5 Version with XDG_CURRENT_DESKTOP=GNOME)

The checkbox comes after the cancel button in the Tab order and will not
activate when pressing enter.

This is how I'll add it to the GTK variant now.

I've implemented this for Qt now.

The Qt5 variant with breeze icon theme looks like the attached screenshot. This
is how it will look on Windows and for KDE plasma 5 users.

If the Qt version is too old (The API for the line edit action was added in
Qt5.2) or there is no icon for the visibility actions it falls back to a textual
checkbox.
This also avoids licensing problems with the icons as the icons are loaded
through QIcon::fromTheme.

Probably a trigger for this, but if a hardware error is causing this it appears
to be recoverable by software otherwise why would restarting gpg-agent /
scdaemon help?

Before the changes to libusb from time to time i had to reenter my pin for
authentication although it should have been cached and in the syslog it showed
the usb disconnect / reconnect. But scdeamon recovered from that.

btw. I can't reproduce this problem if I just disconnect / reconnect the reader
that works as expected.

Just did it.

Werner what is your opinion on this?

pinentry-w32 is broken. It does not handle variable string sizes and there is no
easy way to fix that. Afaik it was never intended as the "default" windows
pinentry but only as a crutch for windows ce experiments.

Would fltk be lightweight enough for your to replace pinentry-w32 in your
installer? In that case I think we should take a serious look at this patch as a
minimal pinentry version for windows.

(And delete pinentry-w32 instead)

GpgOL-1.4 which we will include in 2.3.1 will have an option dialog where you
can enable and disable S/MIME. Default in 1.4 is off.

-> Testing until 2.3.1 is released.

I think this can be resolved. Yes older versions did not allow pasting but
recent versions do allow this. So we've fixed the bug in recent versions ->
resolved. No?

The reporter says he is using ubuntu 14 (i assume 14.4) where the default
pinentry is pinentry-gtk2 0.8.3

I think in my previous messages the most important feature I'm missing was not
clear as I've mostly talked about subkeys and ECC curves. But what really
hinders me in making Kleopatra's key gen dialog more user friendly immediately,
even with default parameters for the key, is the API limit of only one user ID.

Leaving the GUI vs. Commandline argument aside. I still think the batch keygen
API needs to be "modernized"

E.g. with improved authentication support in gnupg 2.1 it will become more
common to generate a key with an authentication subkey. Even the common case of
different Certify / Sign / Encrypt subkeys is not supported by the current API.

Maybe the Curves / Algos can be split up but I think gpgme needs API to query
supported Curves / Algos from GnuPG as this is more dynamic in GnuPG 2.1 then it
has been in previous versions.

The underlying problem is that make clean in gpg4win does not clean up
translations. So they were not regenerated during the build of 3.0.0-beta128 and
the new string was not picked up.

Thanks for reporting.

I've fixed the link.

If i remove the com-certs I get the exact same behavior as I'm seeing on windows.

aheinecke@esus ~/a/e/src> export GNUPGHOME=$(mktemp -d)
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keybox '/tmp/tmp.hyElMR6oUi/pubring.kbx' created
aheinecke@esus ~/a/e/src> gpg2 --import
~/arbeit/gpg4win/zertifikate/testuserA-pub.asc
gpg: /tmp/tmp.hyElMR6oUi/trustdb.gpg: trustdb created
gpg: key 6CFBC912: public key "Test UserA <testusera@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
aheinecke@esus ~/a/e/src> gpgsm -k
gpgsm: keydb_search failed: Invalid argument

From the debug output it looks to me that gnupg is using keyring functions to
work with the keybox.

I can reproduce this now without Kleopatra and on GNU/Linux:

export GNUPGHOME=$(mktemp -d)
gpgsm -k

< imports /opt/gnupg/share/gnupg/com-certs.pem >
(this is not done on windows so maybe the errors differ because of that)

gpg2 --import ~/arbeit/gpg4win/zertifikate/testuserA-pub.asc

Result:

gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_get_keyblock failed: Value not found
gpg: [don't know]: invalid packet (ctb=00)
gpg: /tmp/tmp.f5ub2ZRYC0/pubring.kbx: copy to
'/tmp/tmp.f5ub2ZRYC0/pubring.kbx.tmp' failed: Invalid packet
gpg: error writing keyring '/tmp/tmp.f5ub2ZRYC0/pubring.kbx': Invalid packet
gpg: [don't know]: invalid packet (ctb=00)
gpg: keydb_search failed: Invalid packet
gpg: key 6CFBC912: public key "[User ID not found]" imported
gpg: [don't know]: invalid packet (ctb=00)
gpg: error reading
'/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc': Invalid packet
gpg: import from '/home/aheinecke/arbeit/gpg4win/zertifikate/testuserA-pub.asc'
failed: Invalid packet
gpg: Total number processed: 0
gpg: imported: 1

gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.0-beta307

I'll try now with git master.

The debug output from gnupg for an import that caused a corruped keybox.

It's not for the attached pubring.kbx but I have the file that was generated If
you need it.

What I did in the log was to start kleopatra (The output of process is 2428 is
likely the debug output of the initial keylisting kleopatra did)

Then imported a test key and afterwards closed kleopatra.

Ah nevermind, gpg-agent should probably do cleanups on shutdown to avoid leaking
secrets in memory. So TerminateProcess is no good for this. :-(

I wonder though, how is such a cleanup handled currently on Windows? E.g. If a
user logs out. I would expect some kind of Window Message support but I don't
see any. Only some dead / dummy code in w32main.c.

Werner: Is there a good reason that gpg-agent has to be called with
gpg-connect-agent?

I see several problems with that:

• Multiple Agents in different homedirs. Not really a real world problem but

happens regularly for me in testing.

• Wasting time if no agent is running as it starts an agent just to quit it.
• Multiple users.

And if this fails we can't really handle the error anymore in Gpg4win as we just
call the gnupg-2.1 installer as a subprocess and won't see it if that installer
want's the user to restart.

Do you strongly object to just calling a TerminateProcess on all gpg-agent's we
can access in the uninstallation? This would remove that window and work more
robustly imo.

I've started doing this for GPA and Kleopatra in gpg4win (rev. 929ebdc5-929d94b)
Should I write a similar patch for the GnuPG-2.1 installer?

Reading about
http://www.heise.de/security/meldung/Erpressungs-Trojaner-verschluesselt-mit-PGP-3116677.html

made me think that signing all binaries may not be the best idea. For our
installer we can rule out that it does something malicious as we control what it
does. So signing it is fine. Same goes probably for GpgOL etc.

But the actual encryption stuff (libgcrypt / gnupg) can, of course, be used for
malicious purposes. So there would be the potential for malware using binaries
signed by us. This could hurt our reputation. (technically in terms of Windows
Code Signing Reputation or Anti Virus software)

At least something we should keep in mind while thinking about changes to what
we sign.

Hi,

If Gpg4win was already installed a new install with inst_gpgol=false will not
uninstall it. For this you have to uninstall first.
(With the upcoming gpg4win-3.0.0 we are changing that and are always calling
uninstall first on update.)

You can disable an installed GpgOL by setting the registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\GNU.GpgOL]
"LoadBehavior"=dword:00000000

As this can be overridden on a user level you might also want to check the same
key in HKEY_CURRENT_USER context.

With regards to the crashes. I'm sorry to hear that. We had an extremely nasty
bug that could cause random crashes unrelated to crypto operations ( T1837 )
that bug was only fixed with gpg4win-2.3.0.

Regards,
Andre

I've tested it with pubring now too and it works.
Justus mentioned in jabber that he noticed some more errors after this patch in
the scheme tests. I've not tried them.

I wonder if we could / should use this as a replacement for Pinentry-w32?

Pinentry-w32 should die and FLTK could be lightweight enough that werner would
include it in gnupg-w32?

Hi,

I've looked at the code and everything seems finde there. Config file is read
and if the entry is set the installation section is unselected.

To verify it works:
I've uninstalled gpg4win on a testsystem (Win 10 32 bit but that should really
have no influence at all)

• Verified that GpgOL was unregistered and did not show up in outlook
• Closed outlook
• Installed Gpg4win from the command line: C:\Users\aheinecke>C:\Users\aheinecke\Downloads\gpg4win-2.3.0.exe /S

/C=C:\Users\aheinecke\Desktop\gpg4win.ini

The Gpg4win.ini was minimal and only contained one line:
inst_gpgol=false

-> Confirmed that GpgOL.dll is not installed in the installation direcotry.
-> Confirmed that GpgOL does not show up in Outlook.

Then I've downloaded the gpg4win.ini you've uploaded here and tried again with
that. Still everything works as expected. No GpgOL is installed and it does not
show up in Outlook. Then I've changed inst_gpgex to false in your ini and tried
again and confirmed that GpgEX is also not installed. (Just to verify that
really that file is used.)

Is there something special with the Path where you have the gpg4win.ini ? E.g.
Is it on a Network directory? (This might fail with windows UAC) or does the
Path contain spaces?

Regards,
Andre

Tested this with keybox and it appears to be working. When running a keylist
while importing the import holds for a bit and continues after the keylist.
Not tested this with keyring yet.

I would rather add a "Sign all binaries" installed by us capability to the
packaging process then a special case handling for GpgOL. Especially for the
Uninstaller this would make sense at it requires privileged execution and is
currently unsigned.

But this would mean that we either need to split up the packaging process to
first create the binaries and on a different system (with the code signing
certificate available) create the NSIS Packages.

Or that we expose the CodeSigning certificate to the build system, which
probably makes the most sense as the build system already should be a secured
environment and we only build / execute code which we verified.

I could imagine implementing this as a configure option --with-codesigning-cert
or something thats optional during the build and which you can provide with the
certificate file.

Thanks, now this works as expected for me :-)

since Outlook 2007 there is no Word editor option anymore. We will not add
support for this to Outlook 2003 as Outlook 2003 is End of Life.

Sorry that this bug was never fixed.

Regards,
Andre

Current master b2da3951 segfaults on me.
Btw. I think this is likely because i have a local ID without an Authentication
subkey for aheinecke@gnupg.org

(gdb) run --export-ssh-key aheinecke@gnupg.org
Starting program: /opt/gnupg/bin/gpg2 --export-ssh-key aheinecke@gnupg.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat

Program received signal SIGSEGV, Segmentation fault.
lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116

3116 *ret_keyblock = keyblock; /* Return the keyblock. */
(gdb) bt full
#0 lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116
    rc = 0
    no_suitable_key = 0
    keyblock = 0x0
    found_key = 0x701980

#1 0x0000000000415bb6 in getkey_next (ctx=0x6dd940, pk=0x0, ret_keyblock=0x0)
at ../../g10/getkey.c:1636

rc = <optimized out>
found_key = 0x0

#2 0x000000000045713a in export_ssh_key (ctrl=0x6dd810, userid=0x7fffffffe420
"aheinecke@gnupg.org") at ../../g10/export.c:1437

getkeyctx = 0x6dd940
keyblock = 0x6fd160
desc = {mode = KEYDB_SEARCH_MODE_SUBSTR, skipfnc = 0x0, skipfncvalue =

0x0, sn = 0x0, snlen = 0, u = {

name = 0x7fffffffe420 "aheinecke@gnupg.org", fpr = "

\344\377\377\377\177", '\000' <repeats 17 times>, kid = {

4294960160, 32767}, grip = " \344\377\377\377\177", '\000'

<repeats 13 times>}, exact = 0}

curtime = 1452288169
pk = 0x0
identifier = 0x6ddb80 ""
mb = {len = 0, size = 4096, buf = 0x6e5d70 "", out_of_core = 0}
fp = 0x6dd810
b64_state = {flags = 7199040, idx = 0, quad_count = -153676256, fp =

0x10, stream = 0x6dd800, title = 0x6ddb80 "",

radbuf = "\000\000\000", crc = 0, stop_seen = -1, invalid_encoding =

0, lasterr = 0}

fname = 0x7fffffffe420 "aheinecke@gnupg.org"

#3 0x000000000040dc00 in main (argc=1, argv=0x7fffffffdfe8) at ../../g10/gpg.c:4193

pargs = {argc = 0x7fffffffdb9c, argv = 0x7fffffffdb90, flags = 32769,

err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0,

ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 2,

inarg = 0, stopped = 1,

last = 0x7fffffffe420 "aheinecke@gnupg.org", aliases = 0x0,

cur_alias = 0x0, iio_list = 0x0}}

a = 0x6dd800
orig_argc = 0
orig_argv = 0x6ddb80
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
sl = 0x0
remusr = 0x6ddb40
locusr = 0x0
nrings = 0x0
afx = 0x7fffffffe420
configfp = 0x7fffffffe420
configlineno = 27
parse_debug = 7198720
cmd = aExportSshKey
malloc_hooks = {malloc = 0x405ee0 <gcry_malloc@plt>, realloc = 0x406d40

<gcry_realloc@plt>, free = 0x406290 <gcry_free@plt>}

ctrl = 0x6dd810

Great to hear that! And again let me Thank YOU for your incredible patience and
assistance with logs to help track down / fix this problem. This was really a
nasty bug.

No Kleopatra does not open the pubring. Let's leave kleopatra out of this.

This bug is about multiple GnuPG processes that conflict with each other. See
msg7466 for an example.

Duplicate of T1837

Closing this as noinfo.

Probably the same problem as handled in T1837

Sorry that there has been no response on this but we did not have time to work
on gpgOL.

GpgOL for Outlook 2003 is no longer maintained and support for this in gpg4win
is likely to be dropped soonish.

I'm closing this as nobug to help us clean up the bugtracker. The word editor is
not supported in Outlook 2003 and we will not add support for this. Sorry.

Uhm five years and not reply ;-) Sorry but we did not have much time to work on
GpgOL and the little time we had we spent on Outlook 2010 and later (which is a
different codebase)

The code for 2003 and 2007 is still basically unmaintained. We are looking into
the possibility to remove 2003 support and use the 2010 and later codebase for
2007, too. From your debug output it looks like you are using exchange. This is
not supported for the < 2010 addon. (It is supporeted in the current development
version that will be part of gpg4win 3.0.0)

So you can either switch to Outlook 2010 or later (and for now use the gpg4win
3.0.0 test version) ( https://wiki.gnupg.org/Gpg4win/Testversions ) or hope that
we will enable that codebase for 2007, too.

Sorry that I am marking this as nobug but we will not fix this for 2007 only and
in later versions it already works.

There are several reports about such problems. So far I'm unable to reproduce /
debug this. But we have to look into conditions that might cause this and at
least improve error reporting in these cases.

So far I can only think of that the UIserver socket file
(%APPDATA%\gnupg\S.uiserver) has permissions that kleopatra can not create it.

Renamed the issue to my current understanding of this problem. Locking on
Windows does not work properly.

Yesterday I had a failed Keygeneration while GpgOL's certificate selection
dialog in Kleopatra was open. Tried again and it worked. I did not get Debug
output but the pattern suggests to me that the Certificate selection dialog
looked for changes in the pubring while generating a key and the locking broke
again.

This problem is rising in my priority of Windows Issues as it causes random
failures. There is also a load of similar reports on various channels to be
found through google https://www.google.at/search?q=pubring.bak

This is fixed in GpgOL master.

I've tested to generate an rsa2048 key with backup on a v2.0 card and it works
now. I have not tested restoring from backup etc. But as this report was about
the failed generation, this issue is resolved imo.

Thanks!

Fixed with rev. b879f5b