The bug is pretty obvious. I consider to rewrite it by calling gpgconf
--list-dirs to get the home directory. This would be simliar to what we do in
gpgme. Or well, we could link to to gpgme to and make use of its higher level
interface.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 25 2014
Jul 24 2014
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";
Jul 23 2014
I have some fixes sitting here in my local repo. I need to check them.
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.
Jun 29 2014
May 20 2014
Mar 21 2014
Sep 8 2013
I notice that there are other users with the crash problem who are using a non-
standard location for the home directory, and using GNUPGHOME in the Environment
Variables to point to the homedir.
As an experiment, I tested moving the GNUPGHOME pointer from the "User
variables" to the "System Variables" section of the configuration screen. It
makes NO difference - gpgex crashes Windows 7 Explorer in both scenarios,
although Kleopatra functions as expected in both scenarios.
Sep 6 2013
For diagnostic reasons: could you try with Kleopatra as well?
Maybe this is relevant:
I only installed gpg, gpgEX and GPA from the GPG4Win package.
Using gpg.exe on the command line works perfect.
I can en- and decrypt files and sign and whatnot.
Only gpgEX is affected.
The crash happen regardless of what I did before. Usually I use Q-Dir as file
browser. When I trigger a gpgex action via context menu in one Q-Dir OR Windows
Explorer the program (the one I used) crashes.
I set GNUPGHOME as a user variable via Windows' Extended System Settings.
I followed Bernhard's suggestion and attached the GpgEX debug log.
Please provide a proper bug report so that we are able to replicate this. For
example, how did you set GNUGHOME, what process have been started before that
etc. A complete run trough on how to exhibit the bug would be a appreciated.
Thanks for asking again, I did not remember that GPGex was missing from the
compendium.
It works similiar to GpgOL, see
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gpgex.git;a=blob_plain;f=README;hb=HEAD
and in German:
http://lists.wald.intevation.org/pipermail/gpg4win-users-de/2013-
August/000593.html
Actually, I can't.
The link you provided leads to a site with some general infos.
There is another link into the compendium with infos about
some GPG4Win components but not a single word on gpgex.
So HOW do I provide some more diagnostic output?
Hi Henning,
thanks for your feedback on Gpg4win and of trying the new Gpgex.
Can you help us further by trying to get some more diagnostic output?
See the link in the last section of http://gpg4win.org/reporting-bugs.html
Best,
Bernhard
Sep 5 2013
Sep 2 2013
works with Gpg4win 2.2.0. But there is a failure after decrypting folder with
umlauts: see gpg4win wald issue #6451
(https://wald.intevation.org/tracker/index.php?func=detail&aid=6451&group_id=11&atid=126)
Aug 27 2013
Issue 1530 notes that gpgex crashed Explorer (Win7-64bit) when the Environment
Variable for GNUPGHOME is not at the default setting.
I can confirm this! My configuration is customized, and I am not using the
default path.
Aug 25 2013
I've done more testing, If the gnupg folder is not moved from its default
location gpgex.dll works in v 2.2.0.
The gpgex.dll problem occurs in version 2.2.0 when the user's GNUPGHOME
environment variable has been set to a non-default location (not the user's
default \AppData\Roaming\gnupg)
Kleopatra works fine but for some reason gpgex doesn't work. It produces an
error "Cannot connect to the GnuPG interface (Kleopatra): IPC Connect call failed"
Aug 24 2013
Aug 20 2013
1 month, and not even a single comment. Am I the ONLY person on earth with this
problem, or the ONLY 1 who cares?
Jul 31 2013
OK. The case is closed.
In the Kleopatra screens it is always the primary key that is visible. There was
no expiration date on that key. Looking into the properties of the key, I noticed
that there was an expiration date on the subkey.
So I could sign with the key, but not encrypt.
Jul 30 2013
It seems that one of your keys is not capable of encryption or expired. Thus it
is not be listed for encryption tasks.
Jul 22 2013
Jul 17 2013
Here is some additional information which may be helpful:
(1) Output of Events Viewer
Faulting application name: Explorer.EXE, version: 6.1.7601.17567, time stamp:
0x4d672ee4
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc0000374
Fault offset: 0x00000000000c40f2
Faulting process id: 0x1934
Faulting application start time: 0x01ce82dff437854c
Faulting application path: C:\Windows\Explorer.EXE
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 9f753f17-eee3-11e2-9f80-0016d33c76d0
I hope this is helpful. Thank you.
Jul 16 2013
We released a new Beta yesterday and due to a build glich we will update that
today. Thus I close this bug.
The mailman passwords are by design weak and the web page explictly mentions
that you should not use a valuable password. The admin can anyway see everything.
Jul 14 2013
Most DLLS and exe files have versioninfos - some where not instantly displayed
due to missing language information.
Yes, I'm also used to discover that "the" version info of an assembly must be
EN-US (or default) regardless of the what I wanted to.
I'm now subscriber to the mailing list, although I hate these mailman mailing
lists, because I found out that they're storing passwords in plaintext in their
database (isn't that weird when developing strong encryption tools?)
Jul 1 2013
Last week I posted a revamped version og GpgEX 64 and 32 bit to the gnupg-users
mailing list. You may want to try that one. It is also possible to build a
complete new Gpg4win installer with gpgex 32 and 64 bit. We will release a beta
next week.
Most DLLS and exe files have versioninfos - some where not instantly displayed
due to missing language information.
Jun 27 2013
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
Jun 25 2013
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.
Jun 19 2013
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ß
Jun 18 2013
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
:-(.
Jun 15 2013
Aug 14 2012
Can you please also test with GPA?
Aug 19 2011
Mar 17 2011
Feb 21 2011
Sep 17 2010
You may switch Windows to use the 32 bit explorer version. This solves the problem.
Sep 14 2010
May 13 2010
Mar 26 2010
Mar 15 2010
Obviously not. If someone uses such a filename, it will of course be shown.
Obviously not. If someone uses such a filename, it will of course be shown.
Mar 13 2010
Meanwhile I commited a fix to not encode these special filenames.
Mar 12 2010
Meanwhile I commited a fix to not encode these special filenames.
BTW, what version of GPA or Kleopatra are you using?
This is not a gpgex bug but one of GPA or Kleopatra. They set the filename to
be included.
Mar 10 2010
Dec 23 2009
Well, it shows that the problem is not in gpgex but in Kleopatra.
Dec 22 2009
Hello Werner,
during running gpa --daemon in a shell I can use gpgex without problems. Does
this information help you to solve the problem with kleopatra?
Thanks
Martin
Dec 21 2009
Please try to use gpa instead of Kleopatra:
Dec 16 2009
This is way too old a report to act on it, so I close it. If you still have
issues with the latest gpg4win, please file a new report.
Oct 24 2009
Mar 3 2008
Another suggestion is to run with GPGME_DEBUG=9 in a console and see what the
error reported by the engine is. Also, check if you can run gpg/gpgsm with the
intended operations on the command line.
Feb 12 2008
Just to be sure: What version of gpg4win did you install?