We will need this for 1.9
- Improved parts of our S/MIME support
- Briefly looked at PDF signatures
Yes, its on my agenda.
- dirmngr: Concluded that Happy Eyeballs are too much for dirmngr (and possibly risky for exposure of access).
- gpg: Now, Ed448/X448 can be generated by selecting "Curve 448", just like the pair of Ed25519/Curve25519.
- libgcrypt: constant-time ECC for EdDSA and X448/X25519
- It's available in master
- I'm not sure if it's worth to backport to 1.8
Sun, Jul 5
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?
Sat, Jul 4
Fri, Jul 3
Thu, Jul 2
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.
I edited the task and now you can edit it too.
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.
Wed, Jul 1
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:
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.
Tue, Jun 30
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.
Mon, Jun 29
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). I do not know though, if there is a recommended way to spell it. 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 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.
@dkg while I agree with your aim of
- Backported some of the TPM patches to master. Meanwhile James has adopted the remaining patches.
- Worked on app-nks.c and gpg-card
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...)
- Applied changing UI of GnuPG master "cv448" to specify X448 to align to cv25519
- Pushed Ed448 support in GnuPG: D505: Ed448 support for GnuPG
- Chopstx 2.0 with RISC-V core support
- More change of UI of GnuPG is needed, like Ed25519/Curve25519 pair
- I took T4977: dirmngr not working with linux kernel parameter ipv6.disable=1
- but I don't know the reason why the reporter said : "dirmngr stops working properly."
- Somehow related, I am going to use IPv6 at work this week (IPv6 + IPv4overIPv6).
- In Japan, AAAA filtering of DNS by ISP used to be common (2012-2017).
- Learn Happy Eyeballs: https://tools.ietf.org/html/rfc8305
Sun, Jun 28
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:
Sat, Jun 27
Fri, Jun 26
When I test it on Debian, disabling by,
Please get log of dirmngr, by putting
Thu, Jun 25
Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?
I agree with you that a certificate with a lengthy expiration is not cryptographically sensible or wise, @bernhard -- i'd never want to produce such a certificate myself.