We will need this for 1.9

Yes please.

Yes, its on my agenda.

Since this issue is what I came across when googling for gpg inspect revocation certificate, I thought I’d add what I found out:

I'd be interested, is this is still on the agenda?

So?

Your welcome.

I regret to have distracted your attention. All the above applies to a terminal window (KDE's konsole) in my GUI KDE. On the bare FreeBSD console, everything is fine. So this is a bug in some KDE library or konsole. I'm sorry I did not have the idea to test that on the bare console right away. I'll close this bug here.

Fixed; In master the code already uses our generic scheme parser.

Thanks,
I edited the task and now you can edit it too.

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

Hello Mr. Niibe,

It seems that nl_langinfo(CODESET) returns US-ASCII on your system.

I don't think this fix has made it into a release yet. Could we get a released version of gpgme that contains this fix?

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.

The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

When I took side-by-side comparison of cryptogams version to this patch, what I find is that they are strikingly similar. Operation/instruction ordering matches closely to parts of ghashp8-ppc.pl. In many parts variable/register names are the same also.

Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?

My FreeBSD box is currently not up, so I can't test right now. You may want to look into gnupg/common/utf8conv.c and there set_native_charset(). For historical reasons we start off with latin-1 but then swicth to the selected charset and intialize iconv accordingly. In the case of an error we sometimes fallback to utf-8. You may want to add some debug code (log_debug ("foo bar string=%s\n", some_string);)

in your test, which you did on Linux I guess, utf-8 is written downcase, whereas on my system, it is written uppercase 'UTF-8, conforming to what I find elsewhere (e.g. Wikipedia and RFC 3629). I do not know though, if there is a recommended way to spell it. So the bug might be: gpg does not compare the RFC spelling uppercase, but the linuxism: utf-8 witten downcase. Then the correct fix would be to compare uppercase UTF-8 only, and let Linux fix their system to use the correct uppercase throughout the system... ;)
2nd, I know that FreeBSD has some issues with internationalization: it does not support charsets in their POSIX meaning, but emulates them by combining all available locales and (matching) CODESETs. Usually, this is not a problem, and most translations and handling of UTF-8 works as expected. Maybe this has some subtle effect causing this issue.

Hello Werner,

@dkg while I agree with your aim of

I have the same issue, it worked (I use Kleopatra for a long time), but last week, as usually, I tried to use Kleoptra to encrypt directly, I choose the file and nothing happen (no new windows, nothing at all...)

OpenPGP specifies the use of UTF-8 for all meta data (ie. everything except for the signed/encrypted data). GnuPG has always supported this. I don't known on which OS you are but some don't have UTF-8 support on the command line or tty so you need to tweak your environment first.

I don't know about macOS but the commonly used GNU tools state:

In T4980#135456, @werner wrote:

What do you mean by grep_options?