Probably needs a retest with gpa 0.9.5

Hi thanks for the report and for trying gpa!

Could you try Gpg4win 2.2.2 (or the version 2.2.3 if it is release).
Thanks!

KGPG Should support GnuPg 2.1: https://bugs.kde.org/show_bug.cgi?id=340676

Kleopatra Should support GnuPG 2.1: https://bugs.kde.org/show_bug.cgi?id=340677

No we can't stop doing that. The cleanup function is required to flush the
internal buffers. atexit is a standard C function - dlopen is only a sometimes
useful kludge.

Hm, the suggestion of linking with libgpg-error doesn't really
scale -- think in terms of someone providing pre-built binaries
for e.g. apache and/or php. Where does it end? Should these
programs be linked with all potential otherwise loadable modules?
Why should libgpg-error be special in this regard?

Also, doesn't using atexit() make this problem far worse?
Perhaps libgpg-error can stop doing that, at least?

All kind of problems may appear if you dlopen libgpg-error. It is possible to
do this on Windows due to the very different architecture but Unix/ELF is too
limited to work correctly. The bug you see is just one on the surface - tehre
are lot of other problems below the surface.

In short: Do not dlopen libgpg-error.

You better link apache with libgpg-error so that other dlopen stuff may use the
already loaded code.

BTW, the segmentation faults have been observed
with apache and "stand-alone" php.

D269: 525_patch-src_estream.c

I am sorry, but we don't track bugs for this program here. Please report it to
the bug tracker of gpgtools.org.

The error is now handled by Kleopatra:

http://commits.kde.org/kdepim/2a58b4cb452cdb132553c2381ce810bbc2606e55

I'm a bit scared of regressions, though as the Input handling is so
"generalized" in kleo that I don't know if I now broke cases where input errors
are expected :-/

Attached is a screenshot how it looks now with a broken gpgtar version. And
files are no longer deleted as the operation is no longer thought to be successful.

I try to imagine where the subarch can cause an issue, maybe a big fat warning
when mapping should be sufficient at this point?

For now I will add a note for everyone that opens a bug for this reason to
duplicate the unknown subarch into his own, package will not be compiled
automatically for these.

Thanks!

But that also introduces a new class of bugs. I think it is easier to simply
add a new file. If it eventually turns out that we have too many identical
files, we can change that by adding a mapping table to mkheader.

All PGP 2 support (v3 keys) has been removed from master (2.1). Thus I consider
solved.

Please stop spamming thius bug tracker.

D192: 523_0001-Fix-gpgtar-8-bit-encoding-handling-on-Win32.patch

Werner: Please see attached Patch.

I've tested this with kleopatra and it works now to encrypt a folder which has
special characters in the local code page in filenames. And tested it on the
command line.

This should improve the status quo a lot as full utf16 file names are rarer and
gpgtar / gpg4win is not the only tool which has problems with utf16 filenames ;-)

I did not go for proper unicode support because this would mean:

1. Convert all command line arguments from native to utf8. (Or even to expect

them to be utf-16 *brr*)

2. Expect files-from / stdio file names to be utf8 encoded (and update the callers)
3. Use wide char file io functions. Which would add lots of #ifdefs.

But we would have to discuss if we should do 2. also on non-Windows systems.
Currently gpgtar expects local 8 bit encoding there. So tools using gpgtar would
have to convert their arguments differently for Windows.

Hi,

thanks for reporting this problem.

This has been fixed in the gpg4win sources
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=commit;h=619481b224a9704195c456db74073599d01eac0f

and will be fixed with the next release.

Thank you for working on this problem. I also use GPA 0.9.4 for Windows as gpg
frontend. Would be great if the fix will make the file encryption working with
umlaut also in GPA and kleopatra.

Thank you & Regards
boehmtho

gpgtar correctly returns an exit code != 0 in case an error happens. This exit
code is eaten by kleopatra so the problem that success is reported on error is
on kleos side.

But gpgtar has the encoding problems. From the kleopatra side it looks ok file
names are handed over to gpgtar in local 8 bit encoding and not in utf-8. And
even directly on the command line it fails.

C:\Users\aheinecke\Desktop>"c:\Program Files\GNU\GnuPG\gpgtar.exe" --skip-crypto
--verbose -o c:\Users\aheinecke\Desktop\test.tar -e fäil.txt
gpgtar: error stat-ing `fΣil.txt': The system cannot find the file specified.

The problem is that internally gpgtar treats argument file names as UTF-8 and
even converts the return value from syscalls like findfirstfile to UTF-8 before
opening them. The open uses the utf8 encoded filename and fails as the file
system usually does not use utf8 file names on Windows.

A workaround would be to convert to ACP (CP_ACP (afaik ACP is correct for
filenames)) instead of converting to UTF-8. But this will not work for ?
but as gpgex and kleopatra already fail earlier on "Non 8 bit representable
characters" this should be acceptable for now.

So two fixes need to be done:

• Use system 8 bit encoding for open in gpgtar. -> Should fix most problems
• Handle the return value of gpgtar correctly and escalate it to the user in

kleopatra.

  -> Should make the rest of the problems "uncritical"

I hope to get this done tomorrow evening.

Thanks for reporting this.

This is already part of T1624 although T1624 is confusingly named as it
relates to this problem triggered by gpgex.

We will try to fix it or at least report an error in that case for the next
gpg4win release.

guys i need a help with my Iphone 4 , my girfriend ask me for an app and put
a cable on the mobile nad ask me for the ID now i can not take it out from
the mobile Any sugestions please ?????

Given the low severity of this bug, plus the assurance that v2.1 contains
significant fixes to --list-secret-key, it would be reasonable to close this issue.

FWIW, 2.1 will come with these new commands:

  --quick-gen-key user-id

    This is simple command to generate a standard key with one user
    id.  In contrast to --gen-key the key is generated directly
    without the need to answer a bunch of prompts.  Unless the option
    --yes is given, the key creation will be canceled if the given
    user id already exists in the key ring.

    If invoked directly on the console without any special options an
    answer to a ``Continue?'' style confirmation prompt is required.
    In case the user id already exists in the key ring a second prompt
    to force the creation of the key will show up.

  --quick-sign-key fpr [names]
  --quick-lsign-key fpr [names]

    Directly sign a key from the passphrase without any further user
    interaction.  The fpr must be the verified primary fingerprint of
    a key in the local keyring. If no names are given, all useful user
    ids are signed; with given [names] only useful user ids matching
    one of the- ses names are signed.  The command --quick-lsign-key
    marks the signatures as non-exportable.  If such a non-exportable
    signature already exists the --quick-sign-key turns it into a
    exportable signature.

    This command uses reasonable defaults and thus does not provide
    the full flexibility of the "sign" subcommand from --edit-key.
    Its intended use is to help unattended key signing by utilizing a
    list of verified fingerprints.

The generated header file is, as expected, identical to the one we use
when cross-compling (modulo that we put both versions into one file).
Thus I came up with a simpler solution (see below). I'll commit it soon and a
release will also follow today.

+force_use_syscfg=no
if test "$have_w32_system" = yes; then

AC_DEFINE(HAVE_W32_SYSTEM,1,[Defined if we run on a W32 API based system])
if test "$have_w64_system" = yes; then

@@ -461,11 +462,17 @@ if test "$have_w32_system" = yes; then

  AC_DEFINE(HAVE_W32CE_SYSTEM,1,[Defined if we run on WindowsCE])
  GPG_ERROR_CONFIG_ISUBDIRAFTER="gpg-extra"
fi

+ force_use_syscfg=yes
fi
+if test x$cross_compiling = xyes; then
+ force_use_syscfg=yes
+fi
+
AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)
AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes)
AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes)
AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
+AM_CONDITIONAL(FORCE_USE_SYSCFG, test x$force_use_syscfg = xyes)

AC_DEFINE_UNQUOTED(HOST_TRIPLET_STRING, "$host", [The host triplet])

Modified src/Makefile.am
diff --git a/src/Makefile.am b/src/Makefile.am
index 65f8513..efc5970 100644

• a/src/Makefile.am

+++ b/src/Makefile.am
@@ -262,9 +262,9 @@ parts_of_gpg_error_h = \

 	w32ce-add.h      	\
 	$(lock_obj_pub)

• If we are cross-compiling we better make sure that no stale native
• lock include file will be found by mkheader.

-if CROSS_COMPILING
+# If we are cross-compiling or building on Windows we better make sure
+# that no stale native lock include file will be found by mkheader.
+if FORCE_USE_SYSCFG
pre_mkheader_cmds = -rm lock-obj-pub.native.h 2>/dev/null

There are known problems with listing secret keys but there are no plans to fix
that for 1.4 or 2.0. 2.1 however complete fixes all these list-key vs.
--list-secret-keys differences.

You particular problem might be fixable - I have not yet checked because working
on the 2.1 release is currently more important to me.

GnuPG tried to keep the secring.gpg and the pubring.gpg in sync. However, this
is hard to achieve because it requires lots of code duplication and the syncing
two quite but not complete similar files.

Hello werner,if possible have a look.

Please do not post bug reports for code under develop to the tracker. You may
of course send it to gnupg-devel.

We won't do that. The risk of introducing real bugs is much higher than
detecting possible bugs. You would need to analyze each warning en details. I
did this once but decided to remove the warning from the standard set of cc
options. If you want to dicusss this or post your resuls please do this on
gnupg-devel - this has a much higher chnace that more eyeballs are looking at it.

Note:
Please refer to the ongoing discussion on gnupg-devel.

That is an very experimental feature and you need a patched version of
Libgcrypt. I close this bug; please ask for help on gnupg-devel.

D267: 519_0001-Disable-importing-V3-or-older-public-keys-from-keyse.patch

Fixed patch; previous version included an extra translatable string. And lacked a
semicolon.

D268: 518_0001-Disable-importing-V3-or-older-public-keys-from-keyse.patch

D263: 517_0004-Make-rsa-FIPS-186-4-compliant.patch

D264: 516_0003-PBKDF-Add-the-omitted-step-from-pksc5v2.1-specificat.patch

D265: 515_0002-Make-ecdsa-FIPS-186-4-compliant.patch

D266: 514_0001-Make-dsa-FIPS-186-4-compliant.patch