In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.

The check what Neal introduced is somehow orthogonal to the change of mine.

The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).

fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.

In general, dying outright seems likely to make an observed problem worse than
it needs to be.

FWIW, I added the stricter check. Previously, we specified the header size, but
didn't check that it was respected. When discussing this with Werner, he said
that respecting the header size was important, which is why I chose to die
rather than silently change the header size.

Duplicate of T2374

Duplicate of T2371

Duplicate of T2171

You can now. Thus is not a bug but a feature request.

Note that we do not use Microsoft compilers but use gcc and in cross build
environment.

Duplicate of T2348

Thanks for the output. That indeed confirms my suspicion. Let's read it together:

[...]
libassuan.so.0 =>
/home/ann/gnupg-2.1.11/libassuan-2.4.2/src/.libs/libassuan.so.0 (0x002e4000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0x0066d000)

ldd says which library is used to satisfy a dependency at load time. You see
here that for libassuan.so.0 your newly built library is used. That is good.
However, for libgpg-error.so.0 the library from your system is used which does
not have gpgrt_asprintf, hence the error message in your first log.

What you need to do is to make sure the runtime linker finds your gpg-error
library. Since this kind of problem will occur for each library, it is best to
install all the libraries you built to a common prefix, say /home/ann/local or
/usr/local by specifying --prefix=/my/prefix at configure time, and then to set
LD_LIBRARY_PATH to /my/prefix/lib and include /my/prefix/bin in PATH, so that
gpg-error-config and libassuan-config and co are found at compile time. Feel
free to ask questions if you get stuck.

(If you don't want to do all this by hand, and merely want a working modern
GnuPG, you can also use the 'speedo' framework. See the README in the GnuPG
repository for some hints.)

Thank you. I've attached the output from 'ldd tests/fdpassing'. Not sure how to
read it.

I don't think the bugs are necessarily related. Your issue looks like you build
your own libgpg-error and linked fdpassing against that, but your runtime linker
uses your system-supplied libgpg-error. Try running 'ldd tests/fdpassing' to
see which libgpg-error is used at run-time. Feel free to ask if you need more
assistance.

It has been there since the 21.1 release. The relevant commits are:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b021ef186f6062705a29ae8e3840ad32db451811
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=719349f6d0e464d4f71963b87f6bfa08ac630aa7

@ueno: This is reasonable. Thanks for the explanation. Do you happen to know
approximately what version started to enable these protections?

D315: 782_0001-doc-Make-Emacs-frontend-description-more-accurate.patch

Thanks for writing this up, Neal. However, I found the claim a bit
inaccurate by now. I am attaching a proposed fix for this.

Emacs keeps all key presses buffered.
(You can see the recent key presses by typing @code{C-h l}
(@code{view-lossage}) in emacs.)

This is not the case with the common `read-passwd' function, which
clears the log on every key press. See:
http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/subr.el#n2126

Because of this concern, Emacs doesn't
enable this by default (the user has to run @code{(pinentry-start)},
e.g., from his or her @code{.emacs} file, explicitly).

This is no longer true. Emacs checks the allow-emacs-pinentry option
of gpg-agent, and start it if desired.

Further, Emacs is a huge program,
which doesn't provide any process isolation to speak of. As such,
having it handle the passphrase adds a huge chunk of code to the
user's trusted computing base.

Yes. However, all official packages on elpa.gnu.org are digitally
signed and supposed to work courteously. Users can still use unsigned
or 3rd party packages, but I think it is similar to the situation
where distribution packages are used.

In conclusion, I would say the Emacs pinentry provides the same level
of security as the current pinentry-gtk2 (as long as the
implementation is sane). My only concern was that Emacs `read-passwd'
is implemented in Elisp and thus cannot use secure memory. However,
it is also true for pinentry-gtk2, which uses the default GtkEntry
now.

Let's assume this is the case and the bug has been resolved.

Duplicate of T1837

or well, gcrypt-devel in this case.

Please do not postarbitray pacthes to the tracker. Patches need to go to
gnupg-devel instead.

Thanks for helping keep track of all these issues.

Yes this only fixes the problem that has already been fixed in the last Gpg4win
Versions. So that this will be fixed in future gnupg-2.1 versions.

Still to help us better seperate the problems I would like to close this as for
me this bug was about "Wrong encoding in a localized version".

• the more critical "passphrase with non ASCII characters" problem (as reported

only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?

I actually overlooked this in this issue. Can you please open another issue for
that. And add me to the Nosy.

• the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-

strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)

If this problem was still existing with gpg4win this is still a problem.

• the "charset weirdness searching keyserver for some non-ASCII user IDs under

non-UTF-8 locales" (as reported in Issue 1514).

This appears not to be windows specific. Also I think this works except for
cases where the Key in question is problematic. If I search on windows for
emanuel@intevation.de I get the correct Umlauts shown. Might be a Problem though
for characters that are unrepresentable in the 8 Bit codepage.

It sounds great!

So this patch, as the previous one, solves the "incorrect display of GPG 2
output translated into another language" (as reported here and previously also
in Issue 1373 and Issue 1674).

Does this patch solve also the "incorrect display of filenames with non ASCII
characters" (as reported here and previously also in Issue 1409)?

By the way, as I understand, this patch doesn't fix:

• the more critical "passphrase with non ASCII characters" problem (as reported

only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?

• the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-

strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)

• the "charset weirdness searching keyserver for some non-ASCII user IDs under

non-UTF-8 locales" (as reported in Issue 1514).

Please do not open another bug but comment on the very same bug you posted a few
days ago (issue2166).

In any case, this is a question and not appropriate for a bug tracker. Use one
of the mailing lists for such questions or see https://gnupg.org/service.html
for commercial support offers.

Duplicate of T2166

After some more discussion and testing in the development jabber channel werner
agreed to include this patch. Pushed to libgpg-error with 823e858. So this will
hopefully be part of the first gnupg modern release that will include localization.

D210: 737_0001-Fix-windows-8bit-encoding-conversion.patch

Updated Patch against libgpg-error where this code now lives.

Please apply this patch or something similiar.

The problem I can see is that with this code in libgpg-error now GUI
applications may use it which want to get "GUI Native".

Probably better to introduce a new function "wchar_to_console" ? And use it from
GnuPG. Does GPA use that conversion function?

Might be a good time for this now where gnupg master already depends on new
symbols in libgpg-error.

Current URL was reported in 1495. Closing this issue and leaving that one open.

Removing and readding key helped. Thanks. Seems to be solved in 2.1.9

Please remove your private key(s) of ed25519 and register it again.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798956#24

The same issue in 2.1.9

Duplicate of T1826

Please try the latest 1.3.0 beta version which is available from:

https://wiki.gnupg.org/GpgOL/Development/Testversions

This version has experimental read support for PGP/MIME mails.

I'm closing this issue as a duplicate of T1826 which already tracks PGP-MIME
support in gpgol.

OK, sorry, I didn’t came accross bugs.gnupg.org but directly on another issue.
Will comment on the other one now.

Duplicate of T2050

Please read the first lines of bugs.gnupg.org. Anyway I chnaged your role and
you may now add comments to other items.

For no pinentry pop-up, I think that this is same cause described in the Issue 2112.
Please try the patch in T2112

I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

Fixed in 1.6.4.

Duplicate of T2000

This is the same as T1881

Duplicate of T1881

Forgot to resolve this as superseeded.

With gcrypt compiled with -mstackrealign as analyzed in T2085 this problem
is also fixed.

So I'm marking this as a duplicate of T2085.

Duplicate of T2085

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.