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:
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.
Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.
This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.
Wed, Jun 24
What do you mean by grep_options?
estream_t does not necessary work with stdio or posix calls; that is an implementation detail. For example if you use the mode flag "nonblock" Read/WriteFile are used on Windows.
I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent
Pushed to master as rGa763bb2580b0: gpg,agent: Support Ed448 signing..
Tue, Jun 23
While the initial agent hang problem might be rare, it nevertheless does make sense to have a workaround for this in any case. Especially since it may not be possible to patch this effect away. The commands given by Werner provide this workaround nicely if gpg-connect-agent hangs.
These are very nice commands which I had overlooked. My results:
Update to [rGc94eea15d}.
Hash defaults to SHA512.
Mon, Jun 22
You may start the gpg-agent by hand:
The 5 second timeout is to give the agent time to get ready and accept connections.
The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.
The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?
- Office tasks
- Looked at James' TPM patches and started to port them to master.
- Pushed the change for Ed448 to libgcrypt (no optimization at all): D504: ECC change for Ed448
- Created (and updated) the change for Ed448 to GnuPG: D505: Ed448 support for GnuPG
- Minor clean up in GnuPG to prepare accepting D505
- Tested OpenPGP card v3.4 implementation by Achim
- flashing was done successfully with TTXS reader
- no problem with current GnuPG
- tested against Gnuk's test suite
- found a minor difference: In V3.4, SEX DO factory setting is '0' (Unknown), while it used to be '9' (N/A)
- ISO/IEC 5218 thing
- I don't know if we need to modify GnuPG or not
- Change UI of GnuPG master "cv448" to specify X448 to align to cv25519
- Others: FSIJ accounting of FY2019 and AGM 2020
- I realized that the patch number looks like "SOS" :-)
- For "Ed25519", libgcrypt supports ECDSA as well as EdDSA
- And Gnunet looks like using it (I don't know if it's intended or not)
- I don't know if it works well, I'm afraid cofactor matters
- but for "Ed448", ECDSA is not supported
- Anyway, because of this, a key or sig-data with Ed25519 curve for EdDSA has "(flags eddsa)"
- Learning math for elliptic integral and Jacobi elliptic functions
Minicloud is up. I found that the altivec flags are never passed when libgcrypt is compiled big-endian.
Sat, Jun 20
I am using Duff's device which is not in that version (and makes it considerably simpler), but it certainly is influenced by that version (and the preprocessing of the table taking advantage of the communicative nature of carryless multiplication is novel in that version), and I can add a note to that effect.
Just one question at the moment.
Fri, Jun 19
(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data
Thu, Jun 18
Thanks for the new version. Unfortunately Minicloud seems to be down and therefore cannot test patch at the moment. I'll take look when I regain power64 access.
That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.