This is part of the definition of cleartext signatures.

http://tools.ietf.org/html/rfc4880#section-7.1

   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
   the end of any line is removed when the cleartext signature is
   generated.

I believe the intend is to avoid signature breakeges when one line ending format
is converted.

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.

I've tested this again with the mingw version that is part of ubuntu and it works.

I've commited a patch to gpg4win to enable this and will check if this also
works with the debian wheezy mingw-crt version.

pinentry-qt should have only been the default if you install a gpg4win version
that includes qt.

Could you execute pinetry-qt directly and enter "getpin" in the command line
window that opens?
What happens then?

I've overlooked your bugreport and opened a very similar one
T1685

Werner has commited a proper fix for this in gpgme master.

Thanks for the report anyway. If I had seen this earlier it would have saved me
some time debugging this and coming to the same conclusion ;-)

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!

D209: 447_keylist-shortening.patch

With dirmngr 1.1.1 and libgcrypt-1.6.0 (gpg4win-2.2.2-beta19) I have what I
think is a similar error on Windows:

C:\Users\aheinecke>"c:\Program Files\GNU\GnuPG\dirmngr.exe"
dirmngr[3060]: Fatal: can't register GNU Pth with Libgcrypt: Not supported

Doesn't crash though. I've not tested the pth_init patch. If you think this is
useful please tell me and I will do so. I assume it will also fix this problem.

Thanks for the explanations.

Further analysis showed that the second call to AllowSetForeground window was
blocked by the ForegroundWindowLockTimeout. If you set this timeout to zero
everything worked as expected.

There is a discussion on this under:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/09fa16ba-c6ef-410d-bec2-a99a9b9a98d9/issue-with-foregroundlocktimeout-setforegroundwindow

Which suggests a solution of setting the foregroundlocktimeout to zero before
attempting to set the foreground window. I've found this solution not applicable
for our case as we run into the lock on "AllowSetForegroundWindow" and not when
actually setting the foreground Window.

Another workaround is to call AttachThreadInput on the current foreground thread
call SetForegroundWindow and then detach again. There might be problems with
this approach so it is just used as fallback. But it should resolve this problem
for now.

Ok, thanks I'll check what happens if

5. The agent thinks that the passphrase entered is too weak
6. The agent starts another pinentry
7. The agent sends "getinfo pid" to the pinentry (this i can see)
8. ?

Yes Kleopatra uses gpgme for key generation. Still I don't see how gpgme figures
into this sorry. Should gpgme start gpg-agent and ensure that it has the
setforeground window access right?

1. The gpg-agent asks for a passphrase with pinentry -> set foreground window is

allowed.

2. If that passphrase is weak it launches a new pinentry with a confirm dialog

-> set foreground window is not allowed.

And the agent does not have the right to call allowsetforegroundwindow. In the
first case I think this might be because another component gets the PID of the
pinentry and calls allowsetforeground window (have to do further debugging to
check this)

In the second case afaik only gpg-agent is involved and no one sets
allowsetforeground window on the pid of the second pinentry.

I don't think switching the console to UTF-8 is the real problem here.

At least just using chcp is not enough. Fonts do also factor into this and this
is where it gets weird:

If you run chcp 65001 and have a raster font selected the output is garbled.
If you then switch to a truetype font the output is correctly interpreted.

Now if you run the command while already having a truetype font selected the
output is garbled again but differently.. o.O

And looking at common/utf8conf.c there is already code that tries to handle
different Console Output Codepages but appearently there is a bug somewhere in
there :) (Or that code is not used / respected)

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..

Using gpgme would be nice of course to avoid duplicated functionality (this same
stuff is also implemented in gpgol although without the bug) but remember that
we would then also need a x64 version of gpgme.

Thanks for looking at this. If you like I could test your fixes. I currently
have a build setup and a test setup where I can reproduce the crash.

Btw. Maybe I don't understand c++ enough but afaik this just makes no sense and
is broken:

  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}

should be rather something like:
if (dir)
name = string(dir) + "\\S.uiserver";

issue1530 and T1536 also describe this bug.
I've closed the other two as duplicates as this one was the first.

Closing this as a duplicate of T1516

Duplicate of T1516

This is a duplicate of T1516

Duplicate of T1516

Hi Werner,

I've reproduced this crash. Last trace before the crash is uiserver_connect.

I believe the crash (without having a backtrace) to be caused by the free in
default_socket_name or by that weird cast.

dir = default_homedir ();
if (dir)

{

	  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}
	  free ((void *) dir);

}

    }

default_homedir can return a pointer to an environment variable or a static
string! So just calling free there is definitely a very bad idea.

standard_homedir (which might also be called from default_homedir) also returns
eiher a Heap allocated value or a static string.

I think we should ensure that default_homedir and standard_homedir always return
allocated memory so that it can be safely freed.

The gnupg version mentioned in T1402 (aheinecke on Jun 25 2014, 03:48 PM / Roundup) should be 2.0.22 and not 2.0.18

I can confirm the problem described in the redhat bug still exists. Ran into it
on ubuntu 14.4 with gnupg 2.0.18 (with use-agent in the gpg config).

gpgsm --import <cert> failed with decryption failed without opening pinentry.
But after unsetting GPG_AGENT_INFO it worked.

Mmmh when I run:

#include <stdio.h>
int _dowildcard = -1;
int main (int argc, char **argv)
{

int i = 0;
for ( i = 0; i< argc; i++) {
    printf("%s\n", argv[i]);
}
return 0;

}

With the command line *.* it just prints "*.*". Linking with CRT_glob.o directly
also leads to the same result.

Hi,
there is apparently a compile option "enable-wildcard" for the mingw-w64 c runtime.

But from:
http://mingw-w64.sourcearchive.com/documentation/0~20100125-3/wildcard_8c-source.html

I take it that you can also enable it in the program by defining int _dowildcard

-1;

I'll test it and let you know if this worked.

For the record. This is now optional in pinentry 0.8.4 you can pass
--enable-pinentry-qt4-clipboard to configure to enable clipboard and paste support.

I Just installed gpg4win-vanilla 2.2.1 on a clean VM to check this.
As you can see in the screenshot everything is there and works as expected.

Is it possible that some kind of "Security Software" silently blocked the
installation of libgpg-error for you?

Maybe you could try to install it again into another Directory and check if it
is still missing?

In the backtrace gpa_backtrace2.png you can see that the crash happens:
https://bugzilla.gnome.org/show_bug.cgi?id=696232

If we apply the patch it no longer crashes, but as the error handling in that
patch is just to abort, the text is not copied into the clipboard and we do not
get an error in GPA.

So still some more debugging why invalid utf-8 data is sent from gpa.
As the data worked on comes from GPA and "should" be valid utf-8

Backtrace attached. Sorry that it is an image but windows was blocking me from
copying the gdb output to the clipboard.

Well my suggestion would be that gnupg reads configuration values from
gpg.conf-version AND gpg.conf so that one could keep common options in gpg.conf
and write version specific ones to gpg.conf-version.

But with the ignore-invalid-option option we can at last fix this from the KDE
side. Werner do you have any idea how one can get the list of supported options
from gpg 1 in a reliable way? So that one could check which options are
supported by gpg1 or will there be no options added to gpg1 in the future?

Running gpg on the file directly:

Can you give me an example of how to call gpgtar? From the incomplete details
output of kleopatra and gpgtar --help
I've put together:
C:\>"\Program Files\GNU\GnuPG\gpgtar.exe" -e --openpgp --skip-crypto --output
test.tar.gpg c:\Users\intevation\Desktop\test_bad

Duplicate of T1324

Sorry, after creating this i've noticed that this is a duplicate of issue:
T1324