- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 16 2020
Changes pushed to master.
Jun 15 2020
Pushed the patch to master.
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.
Jun 12 2020
Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.
Jun 11 2020
Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.
Jun 9 2020
Jun 8 2020
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.
Jun 5 2020
Jun 4 2020
Jun 3 2020
Jun 2 2020
Change of gpg-agent for ECC-SOS
I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).
Jun 1 2020
May 29 2020
Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).
May 28 2020
Hand parsing the data object content:
fa 82 01 e2 c1 06 010800001100 c1 06 010c00001100 c1 06 011000001100 c1 09 132a8648ce3d030107 c1 06 132b81040022 c1 06 132b81040023 c1 06 132b8104000a c1 0a 132b2403030208010107 c1 0a 132b240303020801010b c1 0a 132b240303020801010d c1 0a 162b06010401da470f01 c1 0b 162b060104019755010501 c2 06 010800001100 c2 06 010c00001100 c2 06 011000001100 c2 09 122a8648ce3d030107 c2 06 122b81040022 c2 06 122b81040023 c2 06 122b8104000a c2 0a 122b2403030208010107 c2 0a 122b240303020801010b c2 0a 122b240303020801010d c2 0a 162b06010401da470f01 c2 0b 162b060104019755010501 c3 06 010800001100 c3 06 010c00001100 c3 06 011000001100 c3 09 132a8648ce3d030107 c3 06 132b81040022 c3 06 132b81040023 c3 06 132b8104000a c3 0a 132b2403030208010107 c3 0a 132b240303020801010b c3 0a 132b240303020801010d c3 0a 162b06010401da470f01 c3 0b 162b060104019755010501 da 06 010800001100 da 06 010c00001100 da 06 011000001100 da 09 132a8648ce3d030107 da 06 132b81040022 da 06 132b81040023 da 06 132b8104000a da 0a 132b2403030208010107 da 0a 132b240303020801010b da 0a 132b240303020801010d da 0a 162b06010401da470f01 da 0b 162b060104019755010501
And here is (raw) dump of the data object FA:
Here is the dump of "Application Related Data" (6E):
6e 82 01 47 4f 10 d2760001240103040006106160490000 5f 52 08 00730000e0059000 7f 74 03 810120 73 82 01 20 c0 0a 7d000bfe080000ff0000 c1 0b 162b06010401da470f0100 c2 0c 122b06010401975501050100 c3 0b 162b06010401da470f0100 da 06 <-------------------------------------- This is algorithm attributes for Attestation key (Yubikey specific) 010800001100 c4 07 ff7f7f7f030003 c5 50 eeeed1b50b1b1d9c669033fe019e94a27992b44c d00b630fdcb5c4397d5ffbd69aa68a3ff9f8ed10 1b2a3d46f4f0c5afd0115e7eb858d476daf64cdb 0000000000000000000000000000000000000000 <--- This appears to be fingerprint of Attestation key c6 50 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 <--- This appears to be fingerprint of some key related to Attestation key??? cd 10 5e58b1e65e58b1c55e58b1f900000000 de 08 0102020203028102 7f 66 08 02020bfe02020bfe d6 02 0020 d7 02 0020 d8 02 0020 d9 02 0020
May 27 2020
In the SOS branch, rG1c4291c3951d: ecc-sos: Add special leading zero octet removal. should be reverted.
Instead, the S_KEY should be fixed up in read_key_file in findkey.c,
and merge_lists in protect.c.
(Then, no need to be fixed up in extract_private_key.)
Exactly same problem is there in libgcrypt.
In the definitions of curves, it uses negative constant internally in some specific places, but for other parts, we have same problems.
May 26 2020
I should concentrate the case of ECC, in particular, ECC with modern curves.
Removing leading zero from RSA/ECC/ELGamal assuming unsigned integer would result more work.
In libgcrypt, we have another problem of GCRYSEXP_FMT_ADVANCED formatting, which is used by gpg-agent of GnuPG 2.3 with name-value list.
Confusingly, in the SSH specification, it is signed MPI.
See RFC4251, for the definition of "mpint": https://tools.ietf.org/html/rfc4251#page-8
May 25 2020
There are more places for clean up in GnuPG.
While "MPI" in OpenPGP specification is based on unsigned integer, the default "MPI" handling of GnuPG/Libgcrypt is signed. This difference matters internally.
Formatting by "%m" with libgcrypt, it may result prefixed by 0x00 (so that it represents unsigned value, even if scanned as signed).
And because of this, existing private keys in private-keys-v1.d may have this leading zero-byte.
But the counting bits don't count this byte.
May 22 2020
May 21 2020
Fixed in master and applied to 2.2 branch too.
Important interoperability issue:
OpenPGP implementations should implement:
- Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature
Better to paste directly:
# SOS representation # # Initially, it was intended as "Simply, Octet String", but # it is actually "Strange" Octet String. #
I wrote this:
libgpg-error used to be blamed because of this kind of architectural support in earlier stage of building operating system.
T4774 is my try to fix the problem.
Thank you for your work. Please go ahead.
May 20 2020
Sorry, I was reading the next commit (libdns: Avoid using compound literals (3)).
Possibly, it would be dns_p_init which was caught. If so, it's false positive; It returns a pointer given to the function (which is automatic variable of parent function), but it is valid within the scope of parent function.
Could you please show more information, a specific point of the bug?
I can't locate any place where a function returns a pointer to automatic buffer.