- User Since
- Mar 27 2017, 4:47 PM (170 w, 2 d)
It seems that nl_langinfo(CODESET) returns US-ASCII on your system.
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.
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.
Tue, Jun 30
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
- 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
Fri, Jun 26
When I test it on Debian, disabling by,
Please get log of dirmngr, by putting
Wed, Jun 24
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
Update to [rGc94eea15d}.
Hash defaults to SHA512.
Mon, Jun 22
- 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
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
Wed, Jun 17
The changes just follow the existing practice of Ed25519, which does:
Tue, Jun 16
Changes pushed to master.
Mon, Jun 15
- GnuPG change D502: ECC change for SOS pushed to support X448 encryption
- Thanks @werner for backporting rC47e8977d24e5: mpi: Fix flags in mpi_copy for opaque MPI. to libgcrypt 1.8 and rGeeb599c9e261: gpg: Fix for new SOS changes when used with Libgcrypt < 1.8.6.
- Wrote D504: ECC change for Ed448 for libgcrypt to support Ed448
- Got new BasicCard and did mistake to clear its EEPROM
- libgpg-error cross build: T4973: Cross build problem with v1.38
- Consider/test adding Ed448 to GnuPG
- with change of use of "cv448" in current UI from "x448", too
- Test again with new image for OpenPGP 3.4 specification
It's me who should say "thank you".
Or one liner patch would be enough:
IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.
Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.
Fri, Jun 12
Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.
Thu, Jun 11
Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.
Tue, Jun 9
Mon, Jun 8
- Fix libgpg-error cross build probrem
- Pushed gpg-agent better support to SOS for X448
- Created D502: ECC change for SOS
- X448 with SOS
I was wrong. This patch itself doesn't require libgcrypt 1.9. It works with libgcrypt 1.8 well.
I think that the changes for ECC I've done matters:
o rC050e0b4accfa: pubkey: Support a method to get data as an opaque MPI.
o rC05a7d2f262bc: ecc: Support an opaque MPI handling in mpi_from_keyparam.
rC3d5a05767b84: ecc: Fix handling of point representation in EdDSA.
o rC8fce1027c253: ecc: Return an opaque MPI by _gcry_ecc_ec2os.
rC35c1faaea2b0: ecc: String constant fix.
rCad8927f40169: ecc: Simplify _gcry_ecc_compute_public.
o rCc5a7191c1bd1: ecc: Use opaque MPI for _gcry_ecc_mul_point.
rCbbe15758c893: ecc: Fix _gcry_ecc_mont_decodepoint for data by old implementation.
rC27e848666b4a: ecc: ECDH clean up for use of ec->nbits.
rC82441bbb8290: ecc: Fix key generation for ECDH.
rC6d93812aa312: ecc: Fix debug output.
rC6a30a9a2cc48: ecc: Simplify using mpi_ec_t directly.
rC975de3879691: ecc: Fix for NBITS support.
rCe921ad5b3ad0: ecc: Add NAME member to struct mpi_ec_ctx_s.
rC488704be6e04: ecc: Add key generation support to mpi_ec_get_elliptic_curve.
rC5415bc578080: ecc: Consolidate with _gcry_mpi_ec_internal_new.
rCc2aa333dd88b: ecc: Support flags and debug print in _gcry_mpi_ec_internal_new.
rCc7b97ac9bdf9: ecc: Add new function _gcry_mpi_ec_internal_new.
rC10b8cc280a53: ecc: Simplify ecc_encrypt_raw and ecc_decrypt_raw.
rC61a051828253: ecc: More fixes for cofactor with PUBKEY_FLAG_PARAM.
rCa258ae728de6: ecc: Simply use unsigned int for cofactor, not MPI.
rC579d5d6017d6: ecc: Simplify compute_keygrip.
rC95cc9b8f4483: ecc: Clean up key generation code.
o rCff0f1782560e: ecc: Handle ephemeral key as opaque octets.
rC80cf289905ac: ecc: Consolidate encoding a point for Montgomery curve.
rCba0b31f26366: ecc: More clean-up for Ed25519 and Curve25519.
rCd66a4856eb0c: ecc: Fix hard-coded value for 25519 to allow other modern curves.
Fri, Jun 5
Thu, Jun 4
Wed, Jun 3
Jun 2 2020
- For T4954: SOS representation and improvements in GnuPG, I realized that: ideally speaking, T4956: agent: Disrepancy of handling MPI for the interpretation of signed and unsigned and T4964: ecc: Disrepancy of handling MPI for the interpretation of signed and unsigned should be all fixed. But it's too much, very confusing, and possibly will introduce regressions (for SSH and GpgSM for signed data).
- The capacity of my brain is too small to find/identify/fix all possible problems for this.
- So, I'm focusing possible minimal change(s) for real use case of X448/Ed448.
- Tried to flash BC card for 3.4, and failed because of the card is too old. Asked Achim for sending new one.
- Side effect: confirmed that TTXS reader works well on Windows.
- Backport T4934 to 2.2
- Created: T4957: OpenPGP card protocol 3.4 with Yubikey
- continue on ECDH with X448, minimal change for SOS
- Data object FA support in scdaemon, and possible change of gpg-card/gpg--card-edit to show supported key attributes.
Change of gpg-agent for ECC-SOS
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).