From gnutls-devel at lists.gnutls.org Mon Dec 1 05:46:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Dec 2025 04:46:53 +0000 Subject: [gnutls-devel] GnuTLS | record: Allow setting/restoring all record state (!1968) In-Reply-To: References: Message-ID: Alistair Francis commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2923022619 Any more thoughts on this? The ktls-utils implementation is blocked by this -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2923022619 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 1 10:20:47 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Dec 2025 09:20:47 +0000 Subject: [gnutls-devel] GnuTLS | Post-release administrivia (!2047) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 Project:Branches: dueno/gnutls:wip/dueno/release-3.8.11-post to gnutls/gnutls:master Author: Daiki Ueno This adds changes for the next release: * devel/release-steps.md: update CI job name to the latest * abi-dump: update git submodule ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 1 10:20:58 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Dec 2025 09:20:58 +0000 Subject: [gnutls-devel] GnuTLS | Post-release administrivia (!2047) In-Reply-To: References: Message-ID: Alexander Sosedkin was added as a reviewer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 1 19:35:56 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Dec 2025 18:35:56 +0000 Subject: [gnutls-devel] GnuTLS | `gnutls_hash_output(..., NULL)` leads to SIGSEGV (#1769) References: Message-ID: Barnab?s P?cze created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1769 ## Description of problem: `gnutls_hash_output(..., NULL)` can lead to SIGSEGV ## Version of gnutls used: * 3.8.11 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) * Arch Linux ## How reproducible: Steps to Reproduce: * just doing the call triggers it every time (at least on my machine) ## Actual results: ``` Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bd3fcd in _nettle_write_be32 (length=, dst=0x0, src=0x5555555c0d40) at /usr/src/debug/nettle/nettle-3.10.2/write-be32.c:54 54 WRITE_UINT32(dst, src[i]); (gdb) bt full #0 0x00007ffff7bd3fcd in _nettle_write_be32 (length=, dst=0x0, src=0x5555555c0d40) at /usr/src/debug/nettle/nettle-3.10.2/write-be32.c:54 i = words = 8 leftover = 0 #1 0x00007ffff7bd7f25 in nettle_sha256_digest (ctx=0x5555555c0d40, length=, digest=) at /usr/src/debug/nettle/nettle-3.10.2/sha256.c:156 No locals. #2 0x00007ffff6b491fa in wrap_x86_hash_output (src_ctx=, digest=, digestsize=) at accelerated/x86/sha-x86-ssse3.c:329 ctx = __func__ = "wrap_x86_hash_output" [...] ``` ## Expected results: The hash state is reset as indicated in the documentation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1769 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 1 22:43:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Dec 2025 21:43:35 +0000 Subject: [gnutls-devel] GnuTLS | gnutls failure (#1770) References: Message-ID: Dale Radcliff created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1770 I started on the gnome site and was redirected here. (https://discourse.gnome.org/t/tls-handshake-problems/32076) I am trying to figure out why I can't connect Evolution to my mail servers. Using gnutls-cli results in \*\*\* Fatal error: Error in the pull function. for two different mail servers. Can anyone help me diagnose what is going on here so I can fix it. In the past it worked but due to a drive failure I had to set up my mail client again and now I can't connect to two of my mail servers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 01:26:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 00:26:10 +0000 Subject: [gnutls-devel] GnuTLS | `gnutls_hash_output(..., NULL)` leads to SIGSEGV (#1769) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1769#note_2925553837 Thank you for the report; this indeed looks like a bug. There is a test in commit 7a7d3e44c0f769eb7bae6c6ee21a0a8a3f9e5144, but the original test swallows SIGSEGV for some reason and had never exhibited the issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1769#note_2925553837 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 08:59:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 07:59:22 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 Project:Branches: dueno/gnutls:wip/dueno/hash-output to gnutls/gnutls:master Author: Daiki Ueno * tests/slow: set TEST_EXTENSIONS for wrappers * crypto-selftests: exercise gnutls_hash_output(..., NULL) This moves the test introduced in commit 7a7d3e44c0f769eb7bae6c6ee21a0a8a3f9e5144, from tests/slow/hash-large.c to the library selftests, because the former is tailored for excessively large input, ignoring SIGSEGV. * accelerated: accept NULL as digest argument for gnutls_hash_output As a follow-up of commit eced4c0c2b3d3ee6a35dab99616a25910b623f79 this also extends the accelerated version of gnutls_hash_output to be able to reset the context by passing NULL as the digest argument. Fixes: #1769 ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 09:38:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 08:38:20 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Alexander Sosedkin was added as a reviewer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 12:26:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 11:26:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls failure (#1770) In-Reply-To: References: Message-ID: Issue was closed by Alexander Sosedkin Issue #1770: https://gitlab.com/gnutls/gnutls/-/issues/1770 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 12:26:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 11:26:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls failure (#1770) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1770#note_2926581485 This is not a user support forum, this bugtracker is for bugs in gnutls, and your inquiry sounds more like networking problems. Especially since other Fedora 42 / gnutls 3.8.10 users, myself included, can `gnutls-cli imap.mail.att.net:993 -d9` just fine. I suggest you try reproducing your issue 1. with a different internet service provider to rule out their meddling (why would it resolve to 98.137.156.39 for you?), and 2. with a different cryptographic library (e.g., with `openssl s_client imap.mail.att.net:993`). If you arrive at a conclusion that your issue is somehow gnutls-specific, I'd like to direct you towards gnutls-help at lists.gnutls.org or [#gnutls:matrix.org](https://riot.im/app/#/room/#gnutls:matrix.org) then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1770#note_2926581485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 14:25:03 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 13:25:03 +0000 Subject: [gnutls-devel] GnuTLS | Post-release administrivia (!2047) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047#note_2926925779 Reviewer's note to self: I've tried to generate a lossy, but high-SNR version of the abi-dump update so that it'd be humanly reviewable. ``` diff libgnutls elf-function-symbols: +gnutls_audit_current_context +gnutls_audit_pop_context +gnutls_audit_push_context +gnutls_handshake_update_receiving_key +gnutls_psk_allocate_client_credentials2 +gnutls_psk_allocate_server_credentials2 +gnutls_record_get_max_send_size ``` This does match the devel/libgnutls.abignore list. ``` diff libgnutls undefined-elf-function-symbols: +__getdelim -__gmpn_add_n -__gmpn_cmp -__gmpn_sec_add_1 -__gmpn_sec_add_1_itch -__gmpn_sec_div_r -__gmpn_sec_div_r_itch -__gmpn_sec_invert -__gmpn_sec_invert_itch -__gmpn_sec_mul -__gmpn_sec_mul_itch -__gmpn_sec_powm -__gmpn_sec_powm_itch -__gmpz_limbs_finish -__gmpz_limbs_write -__gmpz_size -atoi -atol +dcgettext -dgettext -fdopen -getline -nettle_cnd_memcpy +nettle_rsa_oaep_sha256_decrypt +nettle_rsa_oaep_sha256_encrypt +nettle_rsa_oaep_sha384_decrypt +nettle_rsa_oaep_sha384_encrypt +nettle_rsa_oaep_sha512_decrypt +nettle_rsa_oaep_sha512_encrypt +nettle_sha3_128_init +nettle_sha3_128_shake_output +nettle_sha3_128_update +nettle_sha3_256_shake_output -nettle_sha3_permute -p11_kit_module_initialize +p11_kit_modules_load -p11_kit_modules_load_and_initialize +stpcpy -strcat libdane undefined-elf-function-symbols: +dcgettext -dgettext -fdopen -fprintf -open ``` I'm not sure what happened to `atoi`/`atoi`, but, overall, that list doesn't look concerning to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047#note_2926925779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 2 14:25:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 13:25:34 +0000 Subject: [gnutls-devel] GnuTLS | Post-release administrivia (!2047) In-Reply-To: References: Message-ID: Merge request !2047 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 Project:Branches: dueno/gnutls:wip/dueno/release-3.8.11-post to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewer: Alexander Sosedkin -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 3 00:59:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Dec 2025 23:59:49 +0000 Subject: [gnutls-devel] GnuTLS | Post-release administrivia (!2047) In-Reply-To: References: Message-ID: Merge request !2047 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 Project:Branches: dueno/gnutls:wip/dueno/release-3.8.11-post to gnutls/gnutls:master Author: Daiki Ueno Reviewer: Alexander Sosedkin -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 4 10:08:21 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Dec 2025 09:08:21 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Zolt?n Fridrich was added as a reviewer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 4 10:20:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Dec 2025 09:20:23 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Merge request !2048 was approved by Zolt?n Fridrich Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 Project:Branches: dueno/gnutls:wip/dueno/hash-output to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 4 10:20:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Dec 2025 09:20:38 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2932438776 Don't see any mistakes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2932438776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 4 11:43:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Dec 2025 10:43:35 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/accelerated/afalg.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2932667797 > struct kcapi_handle *handle = ctx; > > + if (digest == NULL) { ... `gnutls_hmac_output` also promises to reset the state, and I don't see that happening. A `digest=NULL` call would get silently swallowed in `_gnutls_mac_output`, and I'm not even sure how does one reach this function with `digest=NULL`. * Why do we need this? * Should it actually do something on the kcapi level instead? * Do we need a similar round of fixes for lib/accelerated/*/hmac*? -- Alexander Sosedkin started a new discussion on lib/crypto-selftests.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2932667818 > + } > + > + /* First feed a dummy content */ nit: "content" is uncountable -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 02:16:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 01:16:25 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) References: Message-ID: Michael Catanzaro created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1771 ## Description of problem: GnuTLS fails to verify the certificate chain on app.usmobile.com: ``` $ gnutls-cli app.usmobile.com Processed 393 CA certificate(s). Resolving 'app.usmobile.com:443'... Connecting to '2606:4700::6812:667:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=app.usmobile.com', issuer `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', serial 0x3d7fb41e831e456921073810e12e6290, EC/ECDSA key 256 bits, signed using ECDSA-SHA256, activated `2025-11-12 18:05:49 UTC', expires `2026-11-12 17:47:06 UTC', pin-sha256="70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc=" Public Key ID: sha1:edd8ffacf5be4501880ac4d61bb967f84583cb6f sha256:ef4cb978bada7d74d53236e9b41ae594ef4cc3c156f5cdb1ba87cd5f2d10aa47 Public Key PIN: pin-sha256:70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc= - Certificate[1] info: - subject `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', issuer `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', serial 0x31eee88afb87cd9ef8336604743f9b27, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-05-29 19:49:45 UTC', expires `2035-05-27 19:49:44 UTC', pin-sha256="44viFzTC+h/L+3OHRg4Rs5v4+AcpzHZvI9Tne2RDNGk=" - Certificate[2] info: - subject `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x00ad8d2df64681a0d36447eaa94fa273c1, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2024-06-21 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="OXyj9ngbqO9cjLeO/+t9Ggl2EP4JTnVWHq4LEwhFM9w=" - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. ``` firefox-145.0.1-1.fc43 accepts this with no problems, so ideally GnuTLS would as well. OpenSSL notably does not accept it (I tested `openssl s_client -connect app.usmobile.com:443`), but OpenSSL is notoriously not very good at certification path building. [SSL Labs](https://www.ssllabs.com/ssltest/analyze.html?d=app.usmobile.com&s=2606%3a4700%3a0%3a0%3a0%3a0%3a6812%3a767) proposes two possible valid certification paths, the second of which won't work by default with gnutls-cli because it requires downloading an intermediate certificate using AuthorityInformationAccess. But the first path probably ought to work? I wonder if there is some good reason to reject it? Daiki says this looks similar to #1741, although notably that issue involves duplicate certs in the certification path, which is not the case here. Here's the certificate chain, for posterity: [test.crt](/uploads/8c2b53dff1008f1bea676cfb912b5b08/test.crt) ## Version of gnutls used: gnutls-3.8.11-5.fc43 with ca-certificates-2025.2.80_v9.0.304-1.1.fc43: ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL): Fedora ## How reproducible: Always Steps to Reproduce: * `gnutls-cli app.usmobile.com` ## Actual results: Chain is rejected as untrusted ## Expected results: Chain should probably(?) verify successfully -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 12:40:17 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 11:40:17 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/accelerated/afalg.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935473188 > { > struct kcapi_handle *handle = ctx; > > + if (digest == NULL) { `gnutls_hmac_output` does reset the state, but doesn't accept NULL as the `digest` argument. The motivation is noted in the commit message of eced4c0c2b3d3ee6a35dab99616a25910b623f79; we need a way to reset the context of SHAKE, so HMAC is out of context here. * Should it actually do something on the kcapi level instead? Probably no, kcapi doesn't support SHAKE. * Do we need a similar round of fixes for `lib/accelerated/*/hmac*`? I don't see the need for it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935473188 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 12:42:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 11:42:05 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/crypto-selftests.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935477770 > } > } > + > + /* Exercise gnutls_hash_output(..., NULL), which > + * resets the hash context > + */ > + if (flags & GNUTLS_SELF_TEST_FLAG_ALL) { > + ret = gnutls_hash_init(&hd, dig); > + if (ret < 0) { > + _gnutls_debug_log("error initializing: %s\n", > + gnutls_digest_get_name(dig)); > + return gnutls_assert_val( > + GNUTLS_E_SELF_TEST_ERROR); > + } > + > + /* First feed a dummy content */ Fixed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935477770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 12:42:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 11:42:05 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: All discussions on merge request !2048 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 13:48:32 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 12:48:32 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/accelerated/afalg.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935629179 > { > struct kcapi_handle *handle = ctx; > > + if (digest == NULL) { Oh, right, I've somehow overlooked that it doesn't accept NULL. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048#note_2935629179 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 13:49:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 12:49:08 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Merge request !2048 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 Project:Branches: dueno/gnutls:wip/dueno/hash-output to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 5 19:07:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Dec 2025 18:07:59 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Andreas Metzler commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2936401832 Hmm. works for me on both Debian testing (3.8.10) and sid (3.8.11) ``` (sid)ametzler at argenau:~$ gnutls-cli app.usmobile.com < /dev/null Processed 150 CA certificate(s). Resolving 'app.usmobile.com:443'... Connecting to '2606:4700::6812:667:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=app.usmobile.com', issuer `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', serial 0x3d7fb41e831e456921073810e12e6290, EC/ECDSA key 256 bits, signed using ECDSA-SHA256, activated `2025-11-12 18:05:49 UTC', expires `2026-11-12 17:47:06 UTC', pin-sha256="70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc=" Public Key ID: sha1:edd8ffacf5be4501880ac4d61bb967f84583cb6f sha256:ef4cb978bada7d74d53236e9b41ae594ef4cc3c156f5cdb1ba87cd5f2d10aa47 Public Key PIN: pin-sha256:70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc= - Certificate[1] info: - subject `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', issuer `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', serial 0x31eee88afb87cd9ef8336604743f9b27, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-05-29 19:49:45 UTC', expires `2035-05-27 19:49:44 UTC', pin-sha256="44viFzTC+h/L+3OHRg4Rs5v4+AcpzHZvI9Tne2RDNGk=" - Certificate[2] info: - subject `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x00ad8d2df64681a0d36447eaa94fa273c1, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2024-06-21 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="OXyj9ngbqO9cjLeO/+t9Ggl2EP4JTnVWHq4LEwhFM9w=" - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) - Session ID: F7:88:DF:EA:BB:42:F6:D3:98:22:56:4A:B3:5E:09:28:DE:2E:60:E1:05:A5:77:12:62:91:A3:59:48:77:6A:0E - Options: OCSP status request, - Handshake was completed - Simple Client Mode: - Peer has closed the GnuTLS connection ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2936401832 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 6 01:19:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 06 Dec 2025 00:19:53 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: All discussions on merge request !2048 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 6 01:21:19 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 06 Dec 2025 00:21:19 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2936853852 In that case, the problem is probably in the PKCS#11 code path. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2936853852 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Dec 7 16:01:50 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Dec 2025 15:01:50 +0000 Subject: [gnutls-devel] GnuTLS | `gnutls_hash_output(..., NULL)` leads to SIGSEGV (#1769) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno with merge request !2048 (https://gitlab.com/gnutls/gnutls/-/merge_requests/2048) Issue #1769: https://gitlab.com/gnutls/gnutls/-/issues/1769 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1769 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Dec 7 16:01:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Dec 2025 15:01:51 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: accept NULL as digest argument for gnutls_hash_output (!2048) In-Reply-To: References: Message-ID: Merge request !2048 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 Project:Branches: dueno/gnutls:wip/dueno/hash-output to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 9 10:51:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Dec 2025 09:51:38 +0000 Subject: [gnutls-devel] GnuTLS | certtool: --verify-profile option does not override system-wide priority configuration (#1772) References: Message-ID: Conor Tull created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1772 When `certtool` is run on a system that utilizes a system-wide priority configuration (via `GNUTLS_SYSTEM_PRIORITY_FILE`), the system-wide defaults appear to take priority over the explicit command-line argument `--verify-profile` . If the system policy enforces a security floor (e.g., 2048-bit RSA), passing `--verify-profile low` fails to allow verification of smaller keys (e.g., 1792-bit), returning a `GNUTLS_SEC_PARAM_MEDIUM` error. **Steps to Reproduce:** 1. On a system with strict crypto-policies or by pointing `GNUTLS_SYSTEM_PRIORITY_FILE` to a strict config. 2. Generate a 1792-bit RSA key and self-signed certificate (simulating legacy artifacts). 3. Attempt to verify the certificate using the `low` profile. `cat < legacy.cfg cn = "Test-Legacy" serial = 001 expiration_days = 1 signing_key encryption_key cert_signing_key ca EOF` `GNUTLS_FORCE_FIPS_MODE=0 certtool --generate-privkey \ --rsa --bits 1792 --outfile 1792.key` `GNUTLS_FORCE_FIPS_MODE=0 certtool --generate-self-signed \ --load-privkey 1792.key \ --template legacy.cfg \ --outfile 1792.pem` `certtool --verify \ --verify-profile low \ --infile 1792.pem --load-ca-certificate 1792.pem` **Actual Results:** The command fails even though `low` was requested. Debug logs (`-d 9`) show that the library asserts `GNUTLS_SEC_PARAM_MEDIUM`, indicating the system default is overriding the CLI flag. `|<2>| GNUTLS_SEC_PARAM_MEDIUM: certificate's security level is unacceptable`\ `Chain verification output: Not verified. The certificate is NOT trusted.` The CLI argument `--verify-profile low` should take precedence over the system configuration file. The user is explicitly opting into allowing weaker keys for this specific operation. If `GNUTLS_SYSTEM_PRIORITY_FILE=''` is included it works successfully. `# This works successfully: GNUTLS_SYSTEM_PRIORITY_FILE='' certtool --verify \ --verify-profile legacy \ --infile 1792.pem --load-ca-certificate 1792.pem ` This suggests the issue is strict precedence logic where the system config is treated as a hard floor rather than a default. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1772 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 9 14:34:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Dec 2025 13:34:39 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2942222823 This is correct behavior, The root certificate `CN=AAA Certificate Services` has been distrusted for TLS by google and Mozilla as is their [policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#74-root-ca-lifecycles), this change has propagated to root stores such as ca-certificates on rhel and fedora. The service provider `app.usmobile.com` should have replaced the intermediate with a newly issued cross-signed certificate https://crt.sh/?id=8505503577 or reissued their leaf/server certificate. Best way to go here is to report it to them. For a **temporary** fix you could add the aforementioned tls distrusted certificate manually to the client. Additional resources: * https://access.redhat.com/solutions/7133942 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2942222823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 9 14:37:26 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Dec 2025 13:37:26 +0000 Subject: [gnutls-devel] GnuTLS | certtool: --verify-profile option does not override system-wide priority configuration (#1772) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1772#note_2942230541 While I'm certainly of an opinion that at least the allowlisting mode of configuration should treat the config values as defaults overrideable with CLI switches / priority strings / etc, I'm having my doubts about the older, default config mode where the values have been treated as hard limits. It could be that we might need differing semantics for differing modes. Oh yeah, and this is a behaviour change, so it might have to go into an appropriately disruptive release. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1772#note_2942230541 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 9 16:43:55 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Dec 2025 15:43:55 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Michael Catanzaro commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2942632716 OK, so then it presumably works in Firefox because Firefox proactively downloads the other possible-but-missing intermediate CA in advance. And it presumably works in Chrome because Chrome would do so when the missing intermediate cert is detected. So the only remaining thing I want to verify here is that GnuTLS calls a `getissuer()` function set by `gnutls_x509_trust_list_set_getissuer_function()`.... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2942632716 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 9 21:27:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Dec 2025 20:27:12 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Michael Catanzaro commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2943262061 OK, I discovered that gnutls-cli actually already supports this via the `--ca-auto-retrieve` option: ``` $ gnutls-cli --ca-auto-retrieve app.usmobile.com Processed 393 CA certificate(s). Resolving 'app.usmobile.com:443'... Connecting to '2606:4700::6812:667:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=app.usmobile.com', issuer `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', serial 0x3d7fb41e831e456921073810e12e6290, EC/ECDSA key 256 bits, signed using ECDSA-SHA256, activated `2025-11-12 18:05:49 UTC', expires `2026-11-12 17:47:06 UTC', pin-sha256="70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc=" Public Key ID: sha1:edd8ffacf5be4501880ac4d61bb967f84583cb6f sha256:ef4cb978bada7d74d53236e9b41ae594ef4cc3c156f5cdb1ba87cd5f2d10aa47 Public Key PIN: pin-sha256:70y5eLrafXTVMjbptBrllO9Mw8FW9c2xuofNXy0Qqkc= - Certificate[1] info: - subject `CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US', issuer `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', serial 0x31eee88afb87cd9ef8336604743f9b27, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-05-29 19:49:45 UTC', expires `2035-05-27 19:49:44 UTC', pin-sha256="44viFzTC+h/L+3OHRg4Rs5v4+AcpzHZvI9Tne2RDNGk=" - Certificate[2] info: - subject `CN=SSL.com TLS Transit ECC CA R2,O=SSL Corporation,C=US', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x00ad8d2df64681a0d36447eaa94fa273c1, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2024-06-21 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="OXyj9ngbqO9cjLeO/+t9Ggl2EP4JTnVWHq4LEwhFM9w=" - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. ``` Unfortunately it still fails to validate. Since browsers can find a valid certification path, ideally GnuTLS would be able to as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2943262061 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 09:50:27 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 08:50:27 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2944248647 I don't think this is the case, afaik when server provides a intermediate that points to a distrusted root, the verification fails and no further attempts are made. The reason this works on firefox, is that Mozilla added a cross-signed intermediate certificate directly to firefox that replaces the server on see(its quiet possible that for chrome it is the same situation). https://fkrenzel.cz/posts/2025-root-ca-mess.html#firefox -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2944248647 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 17:22:56 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 16:22:56 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Michael Catanzaro commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2945655725 Thanks for the blog post link. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2945655725 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 17:23:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 16:23:04 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Issue was closed by Michael Catanzaro Issue #1771: https://gitlab.com/gnutls/gnutls/-/issues/1771 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 18:53:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 17:53:18 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Michael Catanzaro commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2945874272 One comment on your blog post: > There is only one technical workaround we can implement without severely compromising security: including the cross-signed intermediate certificate directly in the root store. However, I do not anticipate shipping such a change before early February. I doubt that the affected service providers will remain broken until then; they will likely fix the issue on their end, which is the correct solution anyway. In practice, we know that websites generally only care about whether major browsers accept the chain. We know that both Firefox and Chrome accept this chain. If it's also accepted by Safari, then probably websites will not make any changes. (If Safari rejects the chain, then most websites will probably eventually notice and fix it.) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2945874272 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 20:57:42 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 19:57:42 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2946168041 Good point, in this case we might have a problem; they haven't even removed the root, probably they have a different policy for distrusting certificates based on lifetime. I will raise this @ Mozilla, they might want to pressure the providers to action by giving a removal date. I don't think they want to keep the intermediate forever. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2946168041 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 10 22:34:29 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Dec 2025 21:34:29 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Michael Catanzaro commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2946364556 Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2946364556 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 11 15:01:58 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Dec 2025 14:01:58 +0000 Subject: [gnutls-devel] GnuTLS | Unable to verify certificate chain on app.usmobile.com (#1771) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2948254275 Raised it with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=2005498 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1771#note_2948254275 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 12 15:11:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 12 Dec 2025 14:11:01 +0000 Subject: [gnutls-devel] GnuTLS | p11tool stopped showing token (#1774) References: Message-ID: Alexander Travov created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1774 ## Description of problem: After recent updates in debian testing `p11tool --list-token-urls` stopped showing my token. No configs changed. `p11-kit list-modules` shows the token. ## Version of gnutls used: Package: gnutls-bin Version: 3.8.11-3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian testing ## Actual results: No ruToken in p11tool output. [p11tool.log](/uploads/a087da8e15e3cc4244b4b2cebc726693/p11tool.log) [p11-kit.log](/uploads/63ed1baa7161dd1abb036189240963b2/p11-kit.log) ## Expected results: ruToken in p11tool output, same as in p11-kit output. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 15 02:57:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Dec 2025 01:57:07 +0000 Subject: [gnutls-devel] GnuTLS | p11tool stopped showing token (#1774) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2953043393 Thank you for the report. My guess is that it has something to do with gnutls!2014 (introduced in 3.8.11), which tries to initialize the module in a thread-safe mode and then falls back, and the logic might not work for your token. If you run p11tool with GNUTLS_DEBUG_LEVEL=3 or higher, maybe you will see some clue in the log. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2953043393 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 15 17:00:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Dec 2025 16:00:48 +0000 Subject: [gnutls-devel] GnuTLS | p11tool stopped showing token (#1774) In-Reply-To: References: Message-ID: Alexander Travov commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2954757937 Thanks for your response, Daiki. I do encounter thread error when run p11tool 3.8.11 with --provider option: ``` $ GNUTLS_DEBUG_LEVEL=3 p11tool --provider=/usr/lib/librtpkcs11ecp.so --list-token-urls gnutls[2]: Enabled GnuTLS 3.8.11 logging... gnutls[2]: getrandom random generator was selected gnutls[2]: Intel SSSE3 was detected gnutls[2]: Intel AES accelerator was detected gnutls[2]: Intel GCM accelerator (AVX) was detected gnutls[2]: cfg: disabling version tls1.0 gnutls[2]: cfg: disabling version tls1.1 gnutls[2]: cfg: disabling version dtls0.9 gnutls[2]: cfg: disabling version dtls1.0 gnutls[2]: cfg: loaded system config /etc/gnutls/config mtime 1765814046 pkcs11_add_provider: Thread locking error ``` with p11tool 3.8.3 on ubuntu 24.04 and the same module library I do not get such error: ``` $ GNUTLS_DEBUG_LEVEL=3 p11tool --provider=/usr/lib/librtpkcs11ecp.so --list-token-urls gnutls[2]: Enabled GnuTLS 3.8.3 logging... gnutls[2]: getrandom random generator was selected gnutls[2]: Intel SSSE3 was detected gnutls[2]: Intel SHA was detected gnutls[2]: Intel AES accelerator was detected gnutls[2]: Intel GCM accelerator (AVX) was detected gnutls[2]: cfg: disabling version tls1.0 gnutls[2]: cfg: disabling version tls1.1 gnutls[2]: cfg: disabling version dtls0.9 gnutls[2]: cfg: disabling version dtls1.0 gnutls[2]: cfg: loaded system config /etc/gnutls/config mtime 1709575231 pkcs11:model=Rutoken%20ECP;manufacturer=Aktiv%20Co.;serial=XXXXXXX;token=XXXXXXXXXXXX <-- token ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2954757937 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 15 22:15:52 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Dec 2025 21:15:52 +0000 Subject: [gnutls-devel] GnuTLS | p11tool stopped showing token (#1774) In-Reply-To: References: Message-ID: Alexander Travov commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2955465972 What catches eye is that name of the module is not detected in new version: `|<2>| p11: Initializing module: (null)` vs `|<2>| p11: Initializing module: /usr/lib/librtpkcs11ecp.so` Why would `p11_kit_module_get_name` return (null)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1774#note_2955465972 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 16 15:52:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Dec 2025 14:52:59 +0000 Subject: [gnutls-devel] GnuTLS | Cross-compile for macOS fails because of broken libdl check (#1775) References: Message-ID: Pierre Ossman (Work account) created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1775 Cross-compiling for macOS doesn't work, and you end up failing to link the library with these errors: ```console ... ld: warning: ignoring file /usr/lib64/libzstd.so, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) ld: warning: ignoring file /usr/lib64/libz.so, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) ld: warning: ignoring file /usr/lib64/libgmp.so, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) ... Undefined symbols for architecture x86_64: "_ZSTD_compress", referenced from: __gnutls_compress in compress.o "_ZSTD_compressBound", referenced from: __gnutls_compress_bound in compress.o ... ``` The problem is that the following macro in `configure.ac` is too primitive and ends up with the wrong result, confusing ld64 and breaking the link: ```m4 AC_LIB_HAVE_LINKFLAGS(dl,, [#include ], [dladdr (0, 0);]) ``` This makes a few bad assumptions: a) That it cannot use `dladdr()` without `libdl` (i.e., it should try looking for the symbol without extra libraries) b) That the link time location of `libdl` matches the runtime location of GnuTLS (two bad assumptions in one), which isn't true when cross compiling End result is that it finds the *Linux* `/usr/lib64/libdl.so` and then blindly adds `-L/usr/lib64 -ldl` to the link line. This then breaks during the link as command line `-L` has priority over the default library paths. ld64 happens to be clever enough to adjust things for the sysroot, but only for paths that actually exist in the sysroot. And `/usr/lib64` does not. Manually trying to find libraries rather than trusting the compiler/environment is very rude behaviour IMHO. I would suggest replacing this with `AC_SEARCH_LIBS()`. Possibly with some override if there is a need to support weird setups. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1775 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 16 16:03:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Dec 2025 15:03:33 +0000 Subject: [gnutls-devel] GnuTLS | Cross-compile for macOS fails because of broken libdl check (#1775) In-Reply-To: References: Message-ID: Pierre Ossman (Work account) commented: https://gitlab.com/gnutls/gnutls/-/issues/1775#note_2957492428 Specifying `--without-libdl-prefix` seems to work around the issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1775#note_2957492428 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: