Thank you.

That could it be. I got an error log that I deemed not to be that interesting,
however it says

LoadedModule[147]=C:\Program Files\GNU\GnuPG\gpgex.dll
File change date: 28.05.2013 18:46

LoadedModule[148]=C:\Program Files\GNU\GnuPG\libgcc_s_sjlj-1.dll
File change date: 28.05.2013 16:34

LoadedModule[149]=C:\Program Files\GtkSharp\2.12\bin\libstdc++-6.dll
File change date: 27.11.2012 06:56

Actually I found some version string in the binary libpngxxx.dll using Notepad,
but no luck in these three files. It would be very useful if you would compile a
VERSIONINFO structure into your binaries. On Windows, using Explorer and also
tools like SysInternals's autoruns (where I disabled the ext) this is really
helpful to find fast and easily a version and publisher info (when overlooking
the system for malicious files, that's a good indicator).

Found a good answer on stackoverflow:

http://stackoverflow.com/questions/598633/gcc-on-windows-set-description-field-
of-c-executable

-----

Sig[0].Name=Anwendungsname
Sig[0].Value=explorer.exe
Sig[1].Name=Anwendungsversion
Sig[1].Value=6.1.7601.17567
Sig[2].Name=Anwendungszeitstempel
Sig[2].Value=4d6727a7
Sig[3].Name=Fehlermodulname
Sig[3].Value=libstdc++-6.dll
Sig[4].Name=Fehlermodulversion
Sig[4].Value=0.0.0.0
Sig[5].Name=Fehlermodulzeitstempel
Sig[5].Value=50b4b868
Sig[6].Name=Ausnahmecode
Sig[6].Value=c0000005
Sig[7].Name=Ausnahmeoffset
Sig[7].Value=0007aed1
DynamicSig[1].Name=Betriebsystemversion
DynamicSig[1].Value=6.1.7601.2.1.0.768.3
DynamicSig[2].Name=Gebietsschema-ID
DynamicSig[2].Value=1031
DynamicSig[22].Name=Zusatzinformation 1
DynamicSig[22].Value=ef31
DynamicSig[23].Name=Zusatzinformation 2
DynamicSig[23].Value=ef31968b50046133f9fdd00fc890a1a4
DynamicSig[24].Name=Zusatzinformation 3
DynamicSig[24].Value=1008
DynamicSig[25].Name=Zusatzinformation 4
DynamicSig[25].Value=1008829529ade9726731888a07d92dae

Yes. I think we're in agreement that MIME and detached signatures are the best way.

However, the functionality in gpg to check cleartext messages is there. If gpg
is confronted with a cleartext file containing auxilliary data, wouldn't it
better refrain from giving a positive return code when checking that file?

1.13 and 1.14.
3.82.
GNU/Linux.

It is possible that GpgEx picks up wrong versions of the GCC support dlls
libstdc++-6.dll and libgcc_s_sjlj-1.dll. They might have been installed by some
other software. Thus my question whether you use any software which has been
build with gcc.

The problem is that we are not able to define the order of DLL searches for the
explorer plugin. Experiments with a Manifest didn't reveal a solution either.

For that reason the next version will link those support libraries static. The
new 64 bit GpgEX posted to the devel list already uses this.

Which automake version are you using?
Which version of make are you using?
Which OS are you using?

Lines 74, 75 and 76 of agent/Makefile.am are copied near the end of
agent/Makefile.in and then to agent/Makefile. Because of the first of them make
exits. `Makefile:1565: *** missing separator (did you mean TAB instead of 8
spaces?). Stop.'

For completeness, this fix has been published as part of the regular Gpg4win
releases since 2.1.1-beta1. It is also included in 2.1.1. There is no need to
download the dll directly, just move to the recent Gpg4win version.

I can't see any problem with this Makefile.am. Maybe your automake version is
broken.

D177: 381_0001-Fix-Makefile.am-indentation.patch

Hello Werner,

D176: 380_libcurl.m4.diff

GnuPG uses setrlimit do disable core dumps. It has always done so. See
common/sysutils.c:disable_core_dumps. Do you have a test case which shows that
it does not work?

Here I found some documents that may help, but I don't know if this is actually the
crash failure.

How to Digitally Sign Microsoft Files (.exe, .cab, .dll, .ocx, .msi, .xpi)
http://www.thegeekstuff.com/2010/03/microsoft-digital-signatures/

Making Your Application UAC Aware
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware

PS: Only other non-default extensions I'm using are 7-Zip, FileZilla, Hermann
Schinagl's LinkShellExtension and Malwarebytes. However disabling GpgEx.dll solved the
problem.

I'm running Win7 x86 HomePremium German. I installed by a mingw release by
extracting somewhere, but don't use it. I'm usually using VS2010 for C#/Web.

The issue was (the unsigned) gpgex library, registered for File and Directory
context menus in Windows Explorer. Without disabling the extension, this rendered
Windows Explorer unusable.

For users will be no other option than uninstalling.

Look here for actually valid certificates:
http://www.trustcenter.de/en/infocenter/root_certificates_601.htm

Gruß

Fix in master (ff84d8d). Thanks.

Please recall that gpg is a Unix command line tool and as such it need to stcik
to common conventions. Only messages which are deemed to be necessary are
printed. Chnages to the key generation dialog would be veryhard because gpg is
used by several other programs as a backend and they assume a certain order of
prompts.

I suggest that you use one of the graphical frontends for key generation.

Please give more details. What OS are you using, what other explorer extensions
are used and so on. Do you use other software which might have been build using
gcc (mingw)?

Regarding the UI: Welcome to the strange world of S/MIME and X.509
certificates. I can't count the hours I spend looking for a certain certificate
:-(.

My mistake, I missed this part: "This example assumes that two
marginally-trusted keys or one fully-trusted key is needed to validate another
key. The maximum path length is three."

Thanks.

Please provide a proper bug report.

See also T1502

Duplicate of T1493

Please see T1493 - it is very likely the same reasons. I am not abale to
replicate it, though. The workaround is to configure gpgme with
--disable-fd-passing

D175: 379_0001-doc-rename-gpgme_sub_key_t-to-gpgme_subkey_t-to-matc.patch

The lsof looks as expected.

You mean --disable-fd-passing...

Correct it works.

Attached lsof output for the process when does not work.

I don't think it has to do with hardened kernel... as the initial report was
without. I will try to contact the original user.

Thanks. GPGME is waiting for an EOF on the fd used to receive data from gpgsm.
The data is send by the GETAUDITLOG command and afaics all data has been
received. There is a one second timeout in the select which you can see at the
end of the log file.

File descriptor passing is used between gpgme and gpgsm which usually works
nice. We have an problem on Mac OS with that for yet unknown reasons. lsof
might give some insight here. I suggest to configure gpgme with
--disable-fd-logging ro check whether this is really the culprit.

What are the special features of the hardened gentoo kernel?

Thanks for the patch. I slighly modified it and pushed it to master. Will go
into 1.4.2.

Attached.

1.0.2 is more than 8 years old. The code chnaged a lot in the meantime. Feel
free to re-open if the problems persists with 1.4.x?

Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

Thanks. Can you please cd to the build directory gpgme/tests/gpgsm and run
this on the command line (after having canceled the make check):

GPGME_DEBUG=9:/tmp/gpgme.log GNUPGHOME=$(pwd) GPG_AGENT_INFO= ./t-verify

and post the gpgme.log file?

Thanks for your answer, I'll do that then.

Best regards

Loïc Gomez

In order to work around this potential bug I do the following at the moment:

1. Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.

2. Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.

The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.

I further tried to find the action that causes the potential bug with an another
test key as follows:

1. Create a certify-only RSA4096 primary key.

2. Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}

3. Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --

export 0xEEE9979BE8C80E95

4. Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --

export 0xB6BF97893ACA0C17

5. Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95

6. Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt

7. Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}

8. Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.

ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.

If you want to rely on the exit coide, you can't use gpg. There are simply too
many things to consider and everyone has a different policy. I commonly use AWK
scripts to implement such policies by parsing the --status-fd output.

The tool you might want to use is gpgv which has been designed for these
purposes. In fact, it is used by all Linux distros to verify the integrity of
the downloaded packages against a specific keyring. Please check out the gpgv
man page.

It has been told for ages that the value of the exit code is not a reliable way
to get information from gpg. Use the --status-fd information.

To be useful bug report, please specify version number of your program. Also,
please show us your configuration file (if any). Specifically, do you have
enable-ssh-support option for gpg-agent?

To diagnose, please create a file .gnupg/scdaemon.conf with something like:

debug-level guru
debug-all

log-file /var/tmp/scd.log

Let us know the content of the file, when you see the problem.

I analyze this issue. The problem is that the reader only supports:
dwFeatures: 0x000207B2

   02.... Short APDU level exchange

With this condition, application program (GnuPG), which needs to send larger
APDU, requires to use command-chaining. However, current V2 cards doesn't
support command-chaining. Alas, there is no way for application program to
process such a request by its user.

Cases are: decryption and key write to card for larger keys.
We need to detect those cases and should notify error to users, though.

Actually, gpg should not open the keyfiles at all. Well, unless you have enabled
the SELinux hacks. In that case we better register the keyfiles. The fix seems
to be harmless and thus it makes sense to apply it.

Patch has already been posted to the mailing list.

Did not get an email with your comment... just happened to peek.

I am sorry, I forgot to place the link to the bug.

My system:
System uname:
Linux-3.8.6-hardened-x86_64-Intel-R-_Core-TM-_i7-3520M_CPU_@_2.90GHz-with-gentoo-2.2
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
app-shells/bash: 4.2_p45

Attached is my config.log.

At the bug link you will find the user's details.

D174: 375_0001-checks-do-not-access-files-outside-of-build.patch

Will be fixed in 2.0.20.

Thanks for the reminder.