Yes only on Windows. Works for me on GNU/Linux, too.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 28 2015
Only on Windows? A quick check on Unix shows that it works.
Sep 23 2015
Sep 21 2015
1.6.4 has been released
Sep 9 2015
I can't reproduce this problem.
GpgOL tries to talk to Kleopatra through a file in %APPDATA%\gnupg
please make sure the permissions on this folder are correct. If you started
things with Administrator privileges before there might be files in there that
are only accessible for administrators and not with normal user rights.
Sep 4 2015
The GIT master and also the 1.6 branch now has a fix for that problem. A 1.6.4
release sill be done soon.
Sep 2 2015
This problem still occurs with libgcrypt from current master:
libgcrypt 1.7.0-beta259
#0 0x655f24a7 in _gcry_aes_aesni_do_setkey (ctx=0x97f868,
key=0x656621b4 <key_128>
"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>) at rijndael-aesni.c:117
Ooops - I should know it is my installer :-(
1.6.3.
IIRC, we fixed the alignment in Libgcrypt but I am not sure whether this has
been backported to Libgcrypt 1.6. Which libgcrypt version is used?
Forgot to resolve this as superseeded.
Duplicate of T2085
Sep 1 2015
Backtrace with debug symbols:
(gdb) bt full
#0 0x655ea3e9 in aesni_do_setkey (ctx=0xc6f868,
key=0x6565dc10 <key_128.65421>
"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>)
at
/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:248
No locals.
#1 0x655ead8a in do_setkey (ctx=0xc6f868,
key=0x6565dc10 <key_128.65421>
"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>, keylen=16)
at
/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:569
initialized = 1 selftest_failed = 0x0 rounds = 10 i = 1 j = 1 r = 1 t = 13813018 rconpointer = 0 KC = 4 hwfeatures = 1472
#2 0x655eb2b1 in rijndael_setkey (context=0xc6f868,
key=0x6565dc10 <key_128.65421>
"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>, keylen=16)
at
/home/aheinecke/arbeit/gpg4win/src/gnupg-w32-2.1.7/PLAY/src/libgcrypt/cipher/rijndael.c:668
ctx = 0xc6f868
...
info registers
eax 0x6565dc10 1701174288
ecx 0xd25110 13783312
edx 0xc6f868 13039720
ebx 0x0 0
esp 0xc6f760 0xc6f760
ebp 0xc6f760 0xc6f760
esi 0x0 0
edi 0xd24478 13780088
eip 0x655ea3e9 0x655ea3e9 <aesni_do_setkey+31>
eflags 0x10297 [ CF PF AF SF IF RF ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0
disas 0x655ea3e2,0x655ea3ff
Dump of assembler code from 0x655ea3e2 to 0x655ea3ff:
0x655ea3e2 <aesni_do_setkey+24>: mov 0xc(%ebp),%eax 0x655ea3e5 <aesni_do_setkey+27>: movdqu (%eax),%xmm1
> 0x655ea3e9 <aesni_do_setkey+31>: movdqa %xmm1,(%edx)
0x655ea3ed <aesni_do_setkey+35>: aeskeygenassist $0x1,%xmm1,%xmm2 0x655ea3f3 <aesni_do_setkey+41>: pshufd $0xff,%xmm2,%xmm2 0x655ea3f8 <aesni_do_setkey+46>: movdqa %xmm1,%xmm3 0x655ea3fc <aesni_do_setkey+50>: pslldq $0x4,%xmm3
It appears to be that this is crash is due to the fact that windows uses a 4
Byte stack alignment and the movdqa call expects 16 byte alignment.
I've found some info on this here:
http://www.peterstock.co.uk/games/mingw_sse/
I also confirmed that with "-mstackrealign" the crash no longer happens.
Werner: should we add this globaly to the configure options of gcrypt or do you
have a better fix for this?
This issue seems fixed in gnupg-w32-2.1.7.
...
Or printf debugging was the wrong approach here.
Attaching gdb to the agent led to the following backtrace:
#0 0x655ea3e9 in aesni_do_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#1 0x655ead8a in do_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#2 0x655eb2b1 in rijndael_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#3 0x655edadd in selftest_basic_128 () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#4 0x655ede09 in selftest () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#5 0x655eabfc in do_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#6 0x655eb2b1 in rijndael_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#7 0x655cd4ae in cipher_setkey () from C:\Program Files\GnuPG\bin\libgcrypt-20.dll
#8 0x655ce076 in _gcry_cipher_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#9 0x655c2308 in gcry_cipher_setkey () from C:\Program
Files\GnuPG\bin\libgcrypt-20.dll
#10 0x0041aea8 in agent_protect ()
#11 0x004189a9 in store_key ()
#12 0x0041950b in agent_genkey ()
#13 0x00407a5e in cmd_genkey ()
So I've built libgcrypt again with --disable-aesni-support (Which is also what
gpg4win uses). And the crash goes away.
Aug 31 2015
Surprise. This issue is weird.
Agent calls: hash_passphrase in agent/protect.c:do_encryption
I've added a load of debug output there but this is where it crashes.
I've moved the get_standard_s2k_count out of that call to verify that this is
not he crashing part.
My code looks like this:
log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__); unsigned long s2kcnt = get_standard_s2k_count(); log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__); rc = hash_passphrase (passphrase, GCRY_MD_SHA1, 3, iv+2*blklen, s2kcnt, key, keylen); log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__);
The debug output after the hash_passphrase is not reached. The line before is.
But now this is where it gets weird.
With (debug enhanced):
static int
hash_passphrase (const char *passphrase, int hashalgo,
int s2kmode, const unsigned char *s2ksalt, unsigned long s2kcount, unsigned char *key, size_t keylen)
{
/* The key derive function does not support a zero length string for the passphrase in the S2K modes. Return a better suited error code than GPG_ERR_INV_DATA. */ int ret; log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__); if (!passphrase || !*passphrase) return gpg_error (GPG_ERR_NO_PASSPHRASE); log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__); ret = gcry_kdf_derive (passphrase, strlen (passphrase), s2kmode == 3? GCRY_KDF_ITERSALTED_S2K : s2kmode == 1? GCRY_KDF_SALTED_S2K : s2kmode == 0? GCRY_KDF_SIMPLE_S2K : GCRY_KDF_NONE, hashalgo, s2ksalt, 8, s2kcount, keylen, key); log_debug ("%s:%s: Line: %d", __FILE__, __func__, __LINE__); log_debug ("ret: %i ", ret); return ret;
}
I can see the debug line above the return statement is executed and that it
returns 0! But i don't see the call returning to do_encryption.
The only idea explaining this behavior that i have so far is some kind of stack
corruption where has_passphrase tries to return to an invalid pointer. But i
don't see the problem atm.
I did not test 2.1 on windows 10 but 2.0 from gpg4win.
Let's consolidate issues though. To simplify things I resolve all reports
regarding this to my report where I will report on debugging / fixing this in
issue2085.
Duplicate of T2085
Duplicate of T2085
Nope not fixed. But let's track this in T2085.
It's not the pinentry. If i install a working pinentry signing files works but
still the migration fails.
Windows Event logs also report that the agent crashed and the process is not
running afterwards.
issue2085 might be related.
Seeing the same on Windows 10 with latest gnupg-w32 package.
Attached is the gpg.log
Migration suceeds from nearly the same homedir under windows 7.
I think the problem is that pinentry-basic does not work on Windows 8.1 and
later. Although I wonder why this should break the migration as I don't get a
pinentry dialog when migrating on Windows 7. (Or on GNU/Linux platforms for that
matter)
Aug 30 2015
Did you reported that at gnupg-users? Let's discuss things in the mail thread.
Andre tested it on Windows 10 so in general it works. The problem must be due
to your local configuration.
Aug 29 2015
Aug 28 2015
For gpg4win 3.0 this will be a problem again as I no longer patch it.
We have to find a solution here. I do not find it acceptable that gnupg does not
understand globs on windows.
Aug 27 2015
Can you still replicate this with gnupg-w32-2.1.7 ?
Aug 25 2015
The problem is likely due to a bug in libgpg-error. You may want to test the
latest master.
Aug 6 2015
This has since been handled in: T1691
It is fixed in Gpg4win.
Jul 22 2015
If you can't do that we can't help you here. You should contact a commercial
supporter (cf. https://gnupg.org/service.html).
Please note that 1.4.12 has security problems and should be updated anyway.
Jul 21 2015
I can't do it on production environment.
Have to fix it like it is, but still don't know where is an issue.
Jun 30 2015
Probably already fixed.
Jun 26 2015
PS: The second problem is persistent if GPG4Win is installed or not. But
knowing how to handle it, I think it's no real problem.
Hmm, let's see:
GPG with GPG4Win installed (I indented it a bit):
% gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:
after the deinstallation of GPG4Win:
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:
From within the GPG4Win folder:
weber in /c/Program Files (x86)/GNU/GnuPG [13:26:16]
% ./gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GNU\GnuPG\gpg2.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files (x86)\GNU\GnuPG\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files (x86)\GNU\GnuPG\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GNU\GnuPG\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files (x86)\GNU\GnuPG\dirmngr.exe:1:1:
The old scdaemon could be some problem with the setup - I had 2.1.13 installed,
but before filing this bug-report, I used the installer from gnupg.org to udpate
to a current version to re-check the behaviour.
But I think I may have two separate problems here now:
- "Unknown IPC command" on recv-keys (from cmd and zsh) - it seems I can't
reproduce this after reinstalling GPG4Win. Maybe my environment was screwed up
without me noticing it.
- "Unknown IPC command" on gpg-connect-agent <command> /bye (only in zsh) -
this seems to be persistent, but I just noticed if I add an empty argument
between the command and the /bye, I don't get the "Unknown IPC Command".
Which means gpg-connect-agent '' /bye works flawlessly. Maybe something to do
with MSYS2 or zsh.
Sorry for being such a weird case xD
Sorry, I only noticed the properties page and I never use teh task manager
(sysinternals Process Epxlorer is much more useful). The different version
number of scdaemon is an indication that an older version is still installed or
at least running.
To see GnuPG's idea of the installed programs you can use
gpgconf
or to actually test whether they are installed:
gpgconf --check-programs
It's the running process information from the task manager (right-click the
running process, properties) - I would be astonished if Microsoft would screw
even that up.
Just for testing it, I reinstalled GPG4Win:
% gpg-connect-agent 'getinfo version' /bye
D 2.1.5
OK
ERR 67109139 Unknown IPC command <GPG Agent>
% gpg --version
gpg (GnuPG) 2.1.5
[...]
% gpg-connect-agent --version
gpg-connect-agent (GnuPG) 2.1.5
[...]
% scdaemon --version
scdaemon (GnuPG) 2.1.3
So it is using the right executables for gpg-agent, gpg-connect-agent and gpg,
but as long as GPG4Win is installed in another directory, it fails on some IPC
Commands..
Scdaemon seems to be 0.0.2 versions behind, which irritates me a bit. But it's
definitely not the one from GPG4Win.
Values from within the GPG4Win directory:
weber in /c/Program Files (x86)/GNU/GnuPG [13:09:03]
% ./gpg2.exe --version
gpg (GnuPG) 2.0.27 (Gpg4win 2.2.4)
% ./gpg-agent.exe --version
gpg-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)
% ./scdaemon.exe --version
scdaemon (GnuPG) 2.0.27 (Gpg4win 2.2.4)
% ./gpg-connect-agent.exe --version
gpg-connect-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)
The screenshots show the program but not the running process. It is quite
possible that the older one is still running. If that happens again, please run
gpg-connect-agent 'getinfo version' /bye
to show the version of the running gpg-agent.
Jun 25 2015
Oh, and thanks overall for making me uninstall GPG4Win :)
Yes and no.
The gpg-agent process running was definitely the 2.1.5 version (see screenshots).
But nontheless, uninstalling GPG4Win solved the problem.
On a sidenote: I had installed GPG4Win solely for the purpose of using it's
pinentry, as it was playing along with my SmartCard-Reader better than the GnuPG
version (pinentry on the device vs on screen) - but somewhere in one of the
later updates, the GnuPG-Pinentry seems to have caught up - everything works now
with just one installation - thanks :)
Jun 22 2015
In gpg4win there is a kwatchgnupg.exe but it throws an error stating that it is
not "installed" within my $PATH variable. The weird thing is, that I started it
from a command prompt somewhere in my filesystem, so its path is set in my $PATH
variable. Strange ...
In last consequence I even tried it with Wireshark and did not get any results
observing localhost and running the command again.
Isn't the output of the log (posted before) enough information or is there any
other way to collect the information you need?
Jun 20 2015
watchgnupg might be missing in the installer. It should be in gpg4win, though.
Anyway using it on Unix with --tcp is much more convenient.
Jun 18 2015
Sorry, but this is not working for me. I do not find watchgnupg executable and
gnupg.org states that this tool does not exist for windows. Maybe I am not clever
enough to find it.
Anyhow I extended the gpg.conf according to your suggestion. (gpg-agent.conf was
already configured like that) I don't know why there is no additional log file
gpg.conf created. I attached my two config files to this issue.
I deleted the "gpg-v21-migrated" file and rerun "gpg -K --verbose". Attached to
this issue you will find my gpg-agent.log . This time it looks like it has more
output in it than the last time.
Jun 17 2015
Not different than in 2.0. You need to enable logging also for gpg-agent. The
best way to do this is by adding
log-file socket:///temp/S.gnupg-log
debug 1024
to gpg-agent.conf and gpg.conf. gpg-agent.conf is usuallay sufficient.
You may then use
watchgnupg /temp/S.gnupg-log
to view the log in real time. Frankly, under Windows I often use
log-file tcp://1.2.3.4:4711
or
log-file tcp://[2001:db8::1]:4711
along with
watchgnupg --tcp 4711
Jun 16 2015
Would you mind to explain how to enable logging in 2.1?
I tried with --log-file [filename] and --logger-file [filename] but it only
created an empty (0 Bytes) file.
I tried to pipe the output to a file with "gpg -K [--verbose] >
c:\temp\gpg21.log" but this didn't work either. Is the K command supposed to be
"unpipeable"? (The output of "gpg --version" can be piped.)
The "migration succeeded" despite of the I/O errors smells fishy. Can you
please delete the "gpg-v21-migrated" file in
C:/Users/xxxxx/AppData/Roaming/gnupg/ and try again with a log file?
Jun 15 2015
May 11 2015
Please try 2.1.3 or the soon to be released 2.1.4
Apr 22 2015
Mar 24 2015
Fixed for master (2.1).
Will not be backported to 2.0.
Mar 19 2015
Use a backslash and it should work.
Agreed, at most places gpg takes a normal slash just fine and the Windows API is
also specified to work with it. I will consider to also test for a forward slash.