From gnutls-devel at lists.gnutls.org Tue Sep 2 00:02:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Sep 2025 22:02:49 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 Project:Branches: dueno/gnutls:wip/dueno/trust-list to gnutls/gnutls:master Author: Daiki Ueno When modules are initialized without CKF_OS_LOCKING_OK nor custom locking functions, they may skip their internal locking assuming that the applications will take care of thread-safety, which is costly and GnuTLS currently doesn't do that. To mitigate this, this patch changes the module initialization code to tell the modules to guarantee thread-safety by themselves. If they are unable to do that, this falls back to the normal initialization without C_Initialize parameters. This also omits the custom_init flag, which indicated whether the module is initialized with p11_kit_module_initialize or a direct call to C_Initialize, now that modules are always initialized with C_Initialize. Fixes: #1212 ## 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/2014 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 Sep 5 05:34:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 03:34:37 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: align private key signing operations with PKCS #11 specification (!2015) References: Message-ID: Di Wang created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2015 Project:Branches: crrs666/gnutls:master to gnutls/gnutls:master Author: Di Wang * pkcs11: align private key signing operations with PKCS#11 specification According to PKCS#11 specification 5.13.1, to start another C_Sign() operation, C_SignInit() must be called again, otherwise the operation may return with CKR_OPERATION_NOT_INITIALIZED. Modifies the private key signing workflow to follow PKCS #11 specification. ## Checklist * [ ] 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/2015 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 Sep 5 05:36:58 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 03:36:58 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!1965) In-Reply-To: References: Message-ID: Alistair Francis commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965#note_2731508297 Done! I have modified `tests/handshake-write.c` to manually trigger a KeyUpdate using the new `gnutls_handshake_update_receiving_key()` function -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965#note_2731508297 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 Sep 5 05:43:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 03:43:48 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!1965) In-Reply-To: References: Message-ID: Alistair Francis started a new discussion on tests/handshake-write.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965#note_2731512655 > TRANSFER(client, server, MSG, strlen(MSG), buffer, MAX_BUF); > TRANSFER(server, client, MSG, strlen(MSG), buffer, MAX_BUF); > > + /* Trigger a KeyUpdate that won't actually be sent to the client, > + * as handshake_read_func() will drop the message. > + */ > + gnutls_session_key_update(server, GNUTLS_KU_PEER); > + > + /* Manually update the client keys */ > + gnutls_handshake_update_receiving_key(client); As a easy test if you comment this line out the test will fail as the key isn't updated on the client -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965#note_2731512655 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 Sep 5 06:14:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 04:14:51 +0000 Subject: [gnutls-devel] GnuTLS | record: Allow setting all record state (!1968) In-Reply-To: References: Message-ID: Alistair Francis marked merge request !1968 as ready -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968 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 Sep 5 06:26:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 04:26:23 +0000 Subject: [gnutls-devel] GnuTLS | record: Allow setting all record state (!1968) In-Reply-To: References: Message-ID: Alistair Francis commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2731569790 Updated with unit tests and removed the draft status. This is now ready to go -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2731569790 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 Sep 5 08:14:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Sep 2025 06:14:59 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: align private key signing operations with PKCS #11 specification (!2015) In-Reply-To: References: Message-ID: Merge request !2015 was closed by Di Wang Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2015 Project:Branches: crrs666/gnutls:master to gnutls/gnutls:master Author: Di Wang Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2015 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 Sep 6 02:49:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 06 Sep 2025 00:49:22 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) 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/2014 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 Sep 8 04:08:31 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 02:08:31 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: ensure C_SignInit is called before C_Sign (!2016) References: Message-ID: Di Wang created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016 Project:Branches: crrs666/gnutls:master to gnutls/gnutls:master Author: Di Wang * pkcs11: ensure C_SignInit is called before C_Sign According to PKCS#11 specification v3.1 part 5.13.1, C_SignInit must be called before every C_Sign operation, otherwise the operation may return with CKR_OPERATION_NOT_INITIALIZED. Signed-off-by: Di Wang ## Checklist * [ ] 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/2016 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 Sep 8 05:22:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 03:22:49 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: ensure C_SignInit is called before C_Sign (!2016) In-Reply-To: References: Message-ID: Merge request !2016 was closed by Di Wang Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016 Project:Branches: crrs666/gnutls:master to gnutls/gnutls:master Author: Di Wang Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016 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 Sep 8 11:38:15 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 09:38:15 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: ensure C_SignInit is called before C_Sign (!2016) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2735741109 > According to PKCS#11 specification v3.1 part 5.13.1, C_SignInit must be called before every C_Sign operation, otherwise the operation may return with CKR_OPERATION_NOT_INITIALIZED. I know it's already closed, but I don't think this is the case; the [spec](https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.2/pkcs11-spec-v3.2.html#_Toc195693140) says "**To process additional data** (in single or multiple parts), the application MUST call C_SignInit again." In this case, the application calls C_Sign twice, first to determine the length of the signature, and then obtain the signature itself, calculated over the same data. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2735741109 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 Sep 8 12:13:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 10:13:38 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: ensure C_SignInit is called before C_Sign (!2016) In-Reply-To: References: Message-ID: Di Wang commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2735846191 Sorry for these two rubbish MRs, I closed it because I found that it would cause pkcs11 tests to fail. However, it's the case when we were testing on a pkcs11 device "Feitian ePass3000GM". I noticed that the PKCS#11 functionality of GnuTLS is tested using SoftHSM. May I ask if you have ever encountered similar issues when using GnuTLS PKCS#11 functionality with actual hardware devices? Since this code has remain unchanged for 12 years with seemingly no related bug reports, this might be an issue specific to the device we are using. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2735846191 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 Sep 8 13:06:17 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:06:17 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2735997828 > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) maybe get more specific, track whether it's the first or second initialization call and expect specific values of flags on each attempt? this way I'm worrying that the test might be overly forgiving -- Alexander Sosedkin started a new discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2735997863 > + NULL; > + provider->init_args = args; > + if (p11_kit_module_get_flags(module) & P11_KIT_MODULE_TRUSTED || should this call have error checking? -- Alexander Sosedkin started a new discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2735997880 > + gnutls_assert(); > + pkcs11_provider_deinit(&provider); > + char *name = p11_kit_module_get_name(provider.module); should this call have error checking? should it preface pkcs11_provider_deinit? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 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 Sep 8 13:07:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:07:51 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: ensure C_SignInit is called before C_Sign (!2016) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2736003574 No, such a basic functionality is known to work for 12 years :-) Would you mind filing an issue describing what you are trying to achieve and expected/actual results with logs? The log-calls option in p11-kit or [PKCS#11 Spy](https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy) might be helpful to diagnose the issues. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2016#note_2736003574 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 Sep 8 13:25:55 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:25:55 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736050836 > + _gnutls_debug_log( > + "p11: Module %s is initialized in a thread-safe mode\n", > + name); > + } else { > + _gnutls_debug_log( > + "p11: Module %s is initialized NOT in a thread-safe mode\n", > + name); > + } > + free(name); > + > + memset(provider, 0, sizeof(*provider)); > + provider->module = module; > + args.reserved = args.reserved ? strdup((const char *)args.reserved) : > + NULL; > + provider->init_args = args; > + if (p11_kit_module_get_flags(module) & P11_KIT_MODULE_TRUSTED || Sorry, which part? The above `strdup` should clearly need an error checking though (and be replaced with `gnutls_strdup`); I'm updating it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736050836 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 Sep 8 13:27:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:27:33 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736053239 > if (ret < 0) { > gnutls_assert(); > - _gnutls_debug_log("Cannot load PKCS #11 module: %s\n", > + char *name = p11_kit_module_get_name(modules[i]); > + _gnutls_debug_log( > + "Cannot initialize PKCS #11 module: %s\n", > + name); > + free(name); > + return ret; > + } > + > + ret = pkcs11_provider_add(&provider); > + if (ret < 0) { > + gnutls_assert(); > + pkcs11_provider_deinit(&provider); > + char *name = p11_kit_module_get_name(provider.module); Good catch, changed the order. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736053239 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 Sep 8 13:31:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:31:20 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736063807 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) The function (`override_C_Initialize`) is called only once, while the module's C_Initialize is called twice: one is not overridden with this, and the other is. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736063807 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 Sep 8 13:32:16 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:32:16 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736065711 > + _gnutls_debug_log( > + "p11: Module %s is initialized in a thread-safe mode\n", > + name); > + } else { > + _gnutls_debug_log( > + "p11: Module %s is initialized NOT in a thread-safe mode\n", > + name); > + } > + free(name); > + > + memset(provider, 0, sizeof(*provider)); > + provider->module = module; > + args.reserved = args.reserved ? strdup((const char *)args.reserved) : > + NULL; > + provider->init_args = args; > + if (p11_kit_module_get_flags(module) & P11_KIT_MODULE_TRUSTED || I was worrying about `p11_kit_module_get_flags`, and I agree on `strdup`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736065711 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 Sep 8 13:38:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:38:30 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736077577 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) wait, how? I thought `C_GetFunctionList` overrides `C_Initialize`, which is then used both times, with and without the flag. Why would it get overridden in between the two calls? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736077577 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 Sep 8 13:47:26 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:47:26 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736095233 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) Am I right that the first call is [here](https://gitlab.com/gnutls/gnutls/-/merge_requests/2014/diffs#231d64530b66ece6c42d67c19ec4981f1183e470_0_149) and the second call is [here](https://gitlab.com/gnutls/gnutls/-/merge_requests/2014/diffs#231d64530b66ece6c42d67c19ec4981f1183e470_0_163)? For the former, the `lib` is not amended with the `override_*` function, so it's just softhsm. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736095233 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 Sep 8 13:48:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:48:49 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736098045 > + _gnutls_debug_log( > + "p11: Module %s is initialized in a thread-safe mode\n", > + name); > + } else { > + _gnutls_debug_log( > + "p11: Module %s is initialized NOT in a thread-safe mode\n", > + name); > + } > + free(name); > + > + memset(provider, 0, sizeof(*provider)); > + provider->module = module; > + args.reserved = args.reserved ? strdup((const char *)args.reserved) : > + NULL; > + provider->init_args = args; > + if (p11_kit_module_get_flags(module) & P11_KIT_MODULE_TRUSTED || `p11_kit_module_get_flags` doesn't return an error. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736098045 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 Sep 8 13:52:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:52:10 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736106018 > + _gnutls_debug_log( > + "p11: Module %s is initialized in a thread-safe mode\n", > + name); > + } else { > + _gnutls_debug_log( > + "p11: Module %s is initialized NOT in a thread-safe mode\n", > + name); > + } > + free(name); > + > + memset(provider, 0, sizeof(*provider)); > + provider->module = module; > + args.reserved = args.reserved ? strdup((const char *)args.reserved) : > + NULL; > + provider->init_args = args; > + if (p11_kit_module_get_flags(module) & P11_KIT_MODULE_TRUSTED || right, why was I looking at `gnutls_pkcs11_token_get_flags`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736106018 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 Sep 8 13:54:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Sep 2025 11:54:22 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736111166 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) oh, no, what I meant was checking flags on [this](https://gitlab.com/gnutls/gnutls/-/merge_requests/2014/diffs#bee3950cf319ee38e4d31860b79a086019be7c00_251_290) and [this](https://gitlab.com/gnutls/gnutls/-/merge_requests/2014/diffs#bee3950cf319ee38e4d31860b79a086019be7c00_251_295) invocation of `C_Initialize` from `pkcs11_provider_init`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2736111166 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 Sep 9 03:33:27 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 01:33:27 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2737803068 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) Do you mean like [this](https://gitlab.com/gnutls/gnutls/-/merge_requests/2014/diffs#9123d497be2907d5898a4428379e3d0dd309fe00_0_62)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2737803068 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 Sep 9 07:11:24 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 05:11:24 +0000 Subject: [gnutls-devel] GnuTLS | Unable to use RSA key with OAEP metadata for signature (#1734) References: Message-ID: Adrien B?raud created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1734 ## Description of problem: We are transitioning from RSA PKCSv1.5 to OAEP encryption, and are currently facing a possible limitation in the GnuTLS API. To my knowledge, OAEP is an encryption padding scheme which doesn't prevent or forbid the use of an RSA private key for signing. However, using the latest version of GnuTLS, I've been unable to perform signing operation using RSA private keys with OAEP information. ## Version of gnutls used: Any version since 3.8.4. ## How reproducible: ```c gnutls_x509_privkey_t key; gnutls_x509_privkey_init(&key); gnutls_x509_privkey_generate(key, GNUTLS_PK_RSA, 4096, 0); gnutls_x509_spki_t spki; gnutls_x509_spki_init(&spki); gnutls_x509_spki_set_rsa_oaep_params(spki, GNUTLS_DIG_SHA512, nullptr); gnutls_x509_privkey_set_spki(key, spki, 0); gnutls_x509_spki_deinit(spki); gnutls_datum_t dat = { (unsigned char *)"Hello, World!", 13 }; uint8_t sig[4096/8]; size_t sig_size = sizeof(sig); int err = gnutls_x509_privkey_sign_data(key, GNUTLS_DIG_SHA512, 0, &dat, sig, &sig_size); printf("gnutls_x509_privkey_sign_data returned %d: %s\n", err, gnutls_strerror(err)); gnutls_x509_privkey_deinit(key); ``` ## Actual results: This fails with `-50 The request is invalid`. Using the abstract API gives the same result. ## Expected results: It would be useful to be able to use OAEP keys for signing. The GnuTLS doesn't seem to provide any easy way to circumvent this, as it doesn't allow to build an spki of type GNUTLS_PK_RSA to set on the private key, and doesn't provide an API to remove spki information form a private key. The only way would seem to export and import raw key parameters, which doesn't feel proper. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1734 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 Sep 9 08:26:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 06:26:23 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017 Project:Branches: dueno/gnutls:wip/dueno/zeroize-key to gnutls/gnutls:master Author: Daiki Ueno Since 39aaa63a1a4cb8432e090887f38241afb2b264a6, zeroize_temp_key is an alias to zeroize_key, and zrelease_temp_mpi_key is an alias to zrelease_mpi_key. Use the latter directly and also remove _gnutls_free_temp_key_datum. ## 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/2017 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 Sep 9 10:03:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 08:03:04 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: All discussions on merge request !2014 were resolved by Alexander Sosedkin https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 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 Sep 9 10:03:03 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 08:03:03 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on tests/pkcs11/pkcs11-mock4.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2738297498 > + > +#ifdef __sun > +#pragma fini(mock_deinit) > +#pragma init(mock_init) > +#define _CONSTRUCTOR > +#define _DESTRUCTOR > +#else > +#define _CONSTRUCTOR __attribute__((constructor)) > +#define _DESTRUCTOR __attribute__((destructor)) > +#endif > + > +static CK_RV override_C_Initialize(void *args) > +{ > + CK_C_INITIALIZE_ARGS *init_args = args; > + > + if (init_args->flags & CKF_OS_LOCKING_OK) yup! so that we test the new call-twice code more explicitly -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2738297498 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 Sep 9 10:21:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 08:21:05 +0000 Subject: [gnutls-devel] GnuTLS | Unable to use RSA key with OAEP metadata for signature (#1734) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1734#note_2738341988 This is a known and, IMO, reasonable limitation. GnuTLS' mental model is to limit the purpose of the key to signing and encryption specifically after `gnutls_x509_spki_set_rsa_pss_params` or `gnutls_x509_spki_set_rsa_oaep_params` correspondingly, turning them "PSS signing keys" and "OAEP encryption keys" specifically. One should not be using the same RSA key for signing and encryption anyway, for key management hygiene reasons in general, and, IIRC, in RSA case specifically, since signing an message hashing to a attacker-controlled value opens an avenue to attack encryption and vice versa. So, the perceived improperness of exporting raw key parameters might be appropriate, and I'm not sure we want to lift that restriction. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1734#note_2738341988 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 Sep 9 13:55:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 11:55:49 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!1965) In-Reply-To: References: Message-ID: Merge request !1965 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965 Project:Branches: alistair23/gnutls:alistair/key-update to gnutls/gnutls:master Author: Alistair Francis Assignees: Reviewers: -- 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 Sep 9 17:18:00 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Sep 2025 15:18:00 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) In-Reply-To: References: Message-ID: Conor Tull commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017#note_2739605956 Changes do not change any existing behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017#note_2739605956 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 Sep 10 13:40:17 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 11:40:17 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2741867603 > > memset(&info, 0, sizeof(info)); > - pkcs11_get_module_info(module, &info); > + pkcs11_get_module_info(provider->module, &info); > > /* initially check if this module is a duplicate */ > for (i = 0; i < active_providers; i++) { > /* already loaded, skip the rest */ > - if (module == providers[i].module || > + if (provider->module == providers[i].module || > memcmp(&info, &providers[i].info, sizeof(info)) == 0) { > + char *name = p11_kit_module_get_name(provider->module); > _gnutls_debug_log("p11: module %s is already loaded.\n", > name); > + free(name); > return GNUTLS_E_INT_RET_0; what is that return code? is that a success or not? one of the two callees turns that into a 0, one does not... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2741867603 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 Sep 10 13:45:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 11:45:53 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2741924313 > + _gnutls_debug_log( > + "Cannot initialize PKCS #11 module: %s\n", > + name); > + free(name); > + return ret; > + } > + > + ret = pkcs11_provider_add(&provider); > + if (ret < 0) { > + gnutls_assert(); > + char *name = p11_kit_module_get_name(provider.module); > + _gnutls_debug_log("Cannot add PKCS #11 module: %s\n", > name); > + free(name); > + pkcs11_provider_deinit(&provider); > + return ret; previously the code has only logged on errors, now it aborts on the first error, which seems like a significant change -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2741924313 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 Sep 10 13:54:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 11:54:01 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) In-Reply-To: References: Message-ID: Merge request !2017 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017 Project:Branches: dueno/gnutls:wip/dueno/zeroize-key to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- 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 Sep 10 14:12:45 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 12:12:45 +0000 Subject: [gnutls-devel] GnuTLS | x509: embed "NULL" in PBKDF2 algorithm ID params in PKCS#5 (!1912) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1912#note_2742022946 Adds NULL parameters as requested as the second AlgorithmIdentifier sequence member, next to the hmac ID. Was: ``` 0:d=0 hl=4 l=1910 cons: SEQUENCE 4:d=1 hl=2 l= 96 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 83 cons: SEQUENCE 19:d=3 hl=2 l= 50 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 32:d=4 hl=2 l= 37 cons: SEQUENCE 34:d=5 hl=2 l= 15 prim: OCTET STRING {HEX DUMP}:86DD2D7FBC324403D12469BD0A6F54 51:d=5 hl=2 l= 3 prim: INTEGER :0927C0 56:d=5 hl=2 l= 1 prim: INTEGER :10 59:d=5 hl=2 l= 10 cons: SEQUENCE 61:d=6 hl=2 l= 8 prim: OBJECT :hmacWithSHA256 71:d=3 hl=2 l= 29 cons: SEQUENCE 73:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc 84:d=4 hl=2 l= 16 prim: OCTET STRING {HEX DUMP}:69FB39FEEAF8C3A5CD96A28FB54E6EEE 102:d=1 hl=4 l=1808 prim: OCTET STRING {HEX DUMP}:... ``` Became (notice the NULL at offt 72): ``` 0:d=0 hl=4 l=1913 cons: SEQUENCE 4:d=1 hl=2 l= 99 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 86 cons: SEQUENCE 19:d=3 hl=2 l= 53 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 32:d=4 hl=2 l= 40 cons: SEQUENCE 34:d=5 hl=2 l= 17 prim: OCTET STRING {HEX DUMP}:CCC17A349971E90978D07D59A04CAF5548 53:d=5 hl=2 l= 2 prim: INTEGER :2710 57:d=5 hl=2 l= 1 prim: INTEGER :10 60:d=5 hl=2 l= 12 cons: SEQUENCE 62:d=6 hl=2 l= 8 prim: OBJECT :hmacWithSHA256 72:d=6 hl=2 l= 0 prim: NULL 74:d=3 hl=2 l= 29 cons: SEQUENCE 76:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc 87:d=4 hl=2 l= 16 prim: OCTET STRING {HEX DUMP}:817FAE718F7C4436EBDAFDF911945063 105:d=1 hl=4 l=1808 prim: OCTET STRING {HEX DUMP}:... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1912#note_2742022946 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 Sep 10 14:12:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 12:12:51 +0000 Subject: [gnutls-devel] GnuTLS | x509: embed "NULL" in PBKDF2 algorithm ID params in PKCS#5 (!1912) In-Reply-To: References: Message-ID: Merge request !1912 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1912 Project:Branches: dueno/gnutls:wip/dueno/pbkdf2-rfc8018 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- 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 Sep 10 14:16:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 12:16:35 +0000 Subject: [gnutls-devel] GnuTLS | tests/tls13-early-data-neg2: avoid a small memory leak (!1969) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1969#note_2742041452 v2 (7b412cc2bf...26cfb4c7dd) above is just a rebase -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1969#note_2742041452 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 Sep 10 14:21:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Sep 2025 12:21:44 +0000 Subject: [gnutls-devel] GnuTLS | tests/tls13-early-data-neg2: avoid a small memory leak (!1969) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on tests/tls13-early-data-neg2.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1969#note_2742053926 > > if (t < 2) { > /* get the session data size */ > + if (session_data.data) > + gnutls_free(session_data.data); removed the condition in v3 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1969#note_2742053926 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 Sep 11 07:02:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 05:02:30 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017#note_2743757908 Thank you for checking @ctull @asosedkin. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017#note_2743757908 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 Sep 11 07:02:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 05:02:34 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) In-Reply-To: References: Message-ID: Merge request !2017 was set to auto-merge by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017 Project:Branches: dueno/gnutls:wip/dueno/zeroize-key to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- 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 Sep 11 07:26:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 05:26:07 +0000 Subject: [gnutls-devel] GnuTLS | build: unconditionally use zeroize_key/zrelease_mpi_key (!2017) In-Reply-To: References: Message-ID: Merge request !2017 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017 Project:Branches: dueno/gnutls:wip/dueno/zeroize-key to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2017 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 Sep 11 08:17:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 06:17:59 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: All discussions on merge request !2014 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 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 Sep 11 08:18:00 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 06:18:00 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 was reviewed by Daiki Ueno -- Daiki Ueno commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2743835820 > + free(name); > + pkcs11_provider_deinit(&provider); > + return ret; Indeed, this should be a `continue` rather than `return`. I've changed it. -- Daiki Ueno commented on a discussion on lib/pkcs11.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2743835824 > name); > + free(name); > return GNUTLS_E_INT_RET_0; The error code just signifies the module is reinitialized. While the first caller (`gnutls_pkcs11_add_provider`) turns it to 0 as the function returns the value, the second caller (`auto_load`) doesn't need to do that, as it discards `ret`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 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 Sep 11 10:19:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 08:19:39 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Merge request !2014 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 Project:Branches: dueno/gnutls:wip/dueno/trust-list 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 Thu Sep 11 10:35:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 08:35:37 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2744139016 Thank you for the review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014#note_2744139016 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 Sep 11 10:35:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 08:35:44 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Merge request !2014 was set to auto-merge by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 Project:Branches: dueno/gnutls:wip/dueno/trust-list 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 Thu Sep 11 10:45:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Sep 2025 08:45:01 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: try to initialize modules in thread-safe mode (!2014) In-Reply-To: References: Message-ID: Merge request !2014 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2014 Project:Branches: dueno/gnutls:wip/dueno/trust-list 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/2014 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 Sep 15 19:23:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Sep 2025 17:23:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.8.10 triggers valgrind Conditional jump or move depends on uninitialised value(s) (#1738) References: Message-ID: Andreas Metzler created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1738 Hello, gnutls 3.8.10 breaks gsasl's Debian CI test on ppc64el. debian/tests/gsasl-mailutils-gs2krb5-gssapi which fails with: ``` 327s ==2630== Command: /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap ci-255-07bddaf3 19835 -z debci 327s ==2630== 327s Trying ?ci-255-07bddaf3?... 327s * OK IMAP4rev1 327s . CAPABILITY 327s * CAPABILITY IMAP4rev1 NAMESPACE ID IDLE LITERAL+ UNSELECT AUTH=GSSAPI AUTH=ANONYMOUS AUTH=EXTERNAL AUTH=LOGIN AUTH=PLAIN AUTH=SECURID AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=SCRAM-SHA-1 AUTH=SCRAM-SHA-1-PLUS AUTH=SCRAM-SHA-256 AUTH=SCRAM-SHA-256-PLUS AUTH=SAML20 AUTH=OPENID20 AUTH=GSSAPI AUTH=GS2-KRB5 327s . OK CAPABILITY Completed 327s . AUTHENTICATE GSSAPI 327s + 327s ==2630== Conditional jump or move depends on uninitialised value(s) 327s ==2630== at 0x40420F0: strcmp (strcmp.S:76) 327s ==2630== by 0x40198E3: _dl_name_match_p (dl-misc.c:75) 327s ==2630== by 0x401A833: dl_open_worker_begin (dl-open.c:614) 327s ==2630== by 0x400163B: _dl_catch_exception (dl-catch.c:241) 327s ==2630== by 0x401A35F: dl_open_worker (dl-open.c:761) 327s ==2630== by 0x400163B: _dl_catch_exception (dl-catch.c:241) 327s ==2630== by 0x401BCCB: _dl_open (dl-open.c:874) 327s ==2630== by 0x4C873F3: dlopen_doit (dlopen.c:56) 327s ==2630== by 0x400163B: _dl_catch_exception (dl-catch.c:241) 327s ==2630== by 0x40017BB: _dl_catch_error (dl-catch.c:260) 327s ==2630== by 0x4C86CD7: _dlerror_run (dlerror.c:138) 327s ==2630== by 0x4C87503: dlopen_implementation (dlopen.c:71) 327s ==2630== by 0x4C87503: dlopen@@GLIBC_2.34 (dlopen.c:81) 327s ==2630== [...] 327s ==2630== 327s ==2630== HEAP SUMMARY: 327s ==2630== in use at exit: 11,519 bytes in 58 blocks 327s ==2630== total heap usage: 2,773 allocs, 2,715 frees, 397,284 bytes allocated 327s ==2630== 327s ==2630== LEAK SUMMARY: 327s ==2630== definitely lost: 16 bytes in 1 blocks 327s ==2630== indirectly lost: 0 bytes in 0 blocks 327s ==2630== possibly lost: 0 bytes in 0 blocks 327s ==2630== still reachable: 11,503 bytes in 57 blocks 327s ==2630== suppressed: 0 bytes in 0 blocks 327s ==2630== Rerun with --leak-check=full to see details of leaked memory 327s ==2630== 327s ==2630== Use --track-origins=yes to see where uninitialised values come from 327s ==2630== For lists of detected and suppressed errors, rerun with: -s 327s ==2630== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) (--track-origins=yes does not yield additional details). ``` I have run git bisect on master - The error is triggered by [66b78875f1ad28bef852ce44e13f5db5c2175b0c] x509: support decoding of ML-DSA private keys in CHOICE format -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1738 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 Sep 15 19:26:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Sep 2025 17:26:18 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.8.10 triggers valgrind Conditional jump or move depends on uninitialised value(s) (#1738) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1738#note_2752128103 note how there's no gnutls in the stacktrace! apparently there's a valgrind fix for that, see https://issues.redhat.com/browse/RHEL-107900 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1738#note_2752128103 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 Sep 15 19:29:16 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Sep 2025 17:29:16 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.8.10 triggers valgrind Conditional jump or move depends on uninitialised value(s) (#1738) In-Reply-To: References: Message-ID: Andreas Metzler commented: https://gitlab.com/gnutls/gnutls/-/issues/1738#note_2752132125 Thank you @asosedkin -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1738#note_2752132125 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 Sep 15 20:02:45 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Sep 2025 18:02:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.8.10 triggers valgrind Conditional jump or move depends on uninitialised value(s) (#1738) In-Reply-To: References: Message-ID: Issue was closed by Alexander Sosedkin Issue #1738: https://gitlab.com/gnutls/gnutls/-/issues/1738 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1738 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 Sep 16 12:55:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Sep 2025 10:55:07 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-provider-followup2 to gnutls/gnutls:master Author: Daiki Ueno * tests: make pkcs11-provider test self-contained Use p11tool exclusively to avoid pkcs11-tool dependency. * pkcs11: use the same initialization code for provider This makes the pkcs11-provider code use the thread-safe module initialization code introduced in commit aa5f15a872e62e54abe58624ee393e68d1faf689. As the mechanism works over p11-kit managed modules, this switches the "path" config option to using PKCS#11 URI, through the "url" keyword. * pkcs11: use CRYPTOKI_GNU interface in the provider code This mass-rewrites the pkcs11-provider code to match the rest of PKCS#11 support in the library, to be able to share the same module initialization code everywhere. ## 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/2018 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 Sep 16 16:34:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Sep 2025 14:34:18 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2754706049 LGTM. Haven't found any issues. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2754706049 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 Sep 16 16:34:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Sep 2025 14:34:22 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request !2018 was approved by Zolt?n Fridrich Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-provider-followup2 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- 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 Sep 17 21:36:11 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Sep 2025 19:36:11 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on lib/pkcs11/p11_mac.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758501300 > if (key_size != mac->length) > return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > > - params.bExpand = CK_TRUE; > + params.bExpand = true; > params.prfHashMechanism = mac->mech; > > if (info != NULL && info_size != 0) { > - params.pInfo = (CK_BYTE_PTR)info; > + params.pInfo = (unsigned char *)info; these attrnames are guarded by `CRYPTOKI_COMPAT`, which are supposed to be disabled by `CRYPTOKI_GNU`, unless specifically enabled back... how do they work? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758501300 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 Sep 17 21:55:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Sep 2025 19:55:04 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/pkcs11/p11_mac.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758535896 > > - params.bExtract = CK_TRUE; > + params.bExtract = true; these attrnames are guarded by `CRYPTOKI_COMPAT`, which are supposed to be disabled by `CRYPTOKI_GNU`, unless specifically enabled back... how do they work? were they supposed to be changed to non-compat ones? -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758535908 > @itemize > - at item @code{path}: path to the PKCS#11 module. > + at item @code{url}: URL of the PKCS#11 module. if we need to support both names, we might need tests for that. if we can drop support for the old name, we need to be louder about the breakage, since that went into 3.8.10 -- Alexander Sosedkin started a new discussion on tests/pkcs11-provider/test-pkcs11-provider.sh: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758535917 > [provider] > -path = ${MODULE} > +url = pkcs11:model=v1;manufacturer=Kryoptic%20Project;token=Kryoptic%20Token I guess a CI job that exercises it is overdue -- Alexander Sosedkin started a new discussion on tests/pkcs11-provider/test-pkcs11-provider.sh: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2758535923 > -KRYOPTIC_DB="${testdir}/kryoptic.$$.sql" > -export KRYOPTIC_CONF="${testdir}/kryoptic.$$.conf" > +PRIORITY_FILE="${testdir}/gnutls.conf" why drop `$$`, if the testdir is not test-unique? or does it depend on no other tests using gnutls.conf? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 18 04:05:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 02:05:53 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/pkcs11-provider/test-pkcs11-provider.sh: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2759112588 > - > MODULE="/lib64/pkcs11/libkryoptic_pkcs11.so" > if [ ! -f "$MODULE" ]; then > echo "Need Kryoptic module to run this test." > exit 77 > fi > > +. ${srcdir}/scripts/common.sh > +testdir=`create_testdir pkcs11-provider` > + > LABEL="Kryoptic Token" > PIN="12345" > -PRIORITY_FILE="${testdir}/gnutls.$$.conf" > -KRYOPTIC_DB="${testdir}/kryoptic.$$.sql" > -export KRYOPTIC_CONF="${testdir}/kryoptic.$$.conf" > +PRIORITY_FILE="${testdir}/gnutls.conf" testdir should be unique, as it is created using `create_testdir` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2759112588 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 Sep 18 07:46:45 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 05:46:45 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: All discussions on merge request !2018 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 18 07:47:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 05:47:04 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 was reviewed by Daiki Ueno -- Daiki Ueno commented on a discussion on lib/pkcs11/p11_mac.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2759339090 > > - params.bExtract = CK_TRUE; > + params.bExtract = true; Good catch. This part was simply compiled out on the CI, as it is guarded with `#ifdef CKM_HKDF_DERIVE`, which p11-kit 0.25.5 doesn't have it. -- Daiki Ueno commented on a discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2759339095 > @itemize > - at item @code{path}: path to the PKCS#11 module. > + at item @code{url}: URL of the PKCS#11 module. I wouldn't say it's a breakage, as this feature is marked as "experimental", but I added an entry in NEWS. -- Daiki Ueno commented on a discussion on tests/pkcs11-provider/test-pkcs11-provider.sh: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2759339098 > [provider] > -path = ${MODULE} > +url = pkcs11:model=v1;manufacturer=Kryoptic%20Project;token=Kryoptic%20Token This would require a bump of CI image to Fedora 42, so I'd leave it for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 18 12:03:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 10:03:38 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/pkcs11/p11_mac.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2760014015 > params.ulSaltSourceDataLen = salt_size; > params.pPassword = (unsigned char *)key; > params.ulPasswordLen = key_size; more compat names here... but at least `for new in $(grep undef /usr/include/p11-kit-1/p11-kit/pkcs11.h | cut '-d ' -f2); do old=$(grep -F "#define $new " /usr/include/p11-kit-1/p11-kit/pkcs11.h | cut '-d ' -f3); if [[ -n "$old" ]]; then grep -F "$old" lib/pkcs11/* ; fi ; done` suggests it might be the last ones. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 18 13:03:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 11:03:12 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: All discussions on merge request !2018 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 18 13:04:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 11:04:09 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/pkcs11/p11_mac.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2760188630 > attr_key_type = mac->key_type; > > params.saltSource = CKZ_SALT_SPECIFIED; > - params.pSaltSourceData = (unsigned char *)salt; > + params.salt_ptrSourceData = (unsigned char *)salt; > params.ulSaltSourceDataLen = salt_size; > params.pPassword = (unsigned char *)key; > params.ulPasswordLen = key_size; Thanks; the `#ifdef` condition was wrong (it was checking a typedef, not a `#define`). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2760188630 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 Sep 18 20:54:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Sep 2025 18:54:10 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) References: Message-ID: alavrentiev created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1739 Please consider the following retrieval command: ``` $ curl -vi -X POST -d 'qdata=SCVBID:1426270910:2452:210.1002/cne.23771' "https://doi.crossref.org/servlet/query?format=unixref&pid=noreply%40ncbi.nlm.nih.gov" ``` It runs without issues, yet when the retrieval is done with GNUTLS using socket I/O callbacks, it triggers an error when the remote closes the sending end of the connection: ``` 09/18/25 14:52:53 SSOCK#1000[3]@18.205.36.254:443: EOF hit at offset 24398 09/18/25 14:52:53 GNUTLS10: READ: Got 0 bytes from 0x1693330 09/18/25 14:52:53 GNUTLS10: READ: read 0 bytes from 0x1693330 09/18/25 14:52:53 TRACE: GNUTLS error -110(fatal) -> CONNECT GNUTLS status Unknown 09/18/25 14:52:53 TRACE: SSOCK#1000[3]@18.205.36.254:443: The TLS connection was non-properly terminated while reading at offset 24398 ``` When the same code is used with mbedTLS and its callbacks, it completes successfully, just as `curl` does: ``` 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => read 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => read record 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => fetch input 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: in_left: 0, nb_want: 5 09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: EOF hit at offset 24398 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: in_left: 0, nb_want: 5 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: ssl->f_recv(_timeout)() returned 0 (-0x0000) 09/18/25 14:44:28 MBEDTLS1: 0x26d0760: mbedtls_ssl_fetch_input() returned -29312 (-0x7280) 09/18/25 14:44:28 MBEDTLS1: 0x26d0760: ssl_get_next_record() returned -29312 (-0x7280) 09/18/25 14:44:28 TRACE: SSOCK#1000[3]@18.205.36.254:443: Read 0 bytes at offset 24398 09/18/25 14:44:28 TRACE: MbedTlsClose(0x26d0760): Enter 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => write close notify 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => send alert message 09/18/25 14:44:28 MBEDTLS3: 0x26d0760: send alert level=1 message=0 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => write record 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => encrypt buf 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'before encrypt: output payload' (2 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 01 00 .. 09/18/25 14:44:28 MBEDTLS3: 0x26d0760: dumping 'CID' (0 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'IV used (internal)' (12 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: dd 92 25 b2 6b 24 cd 49 32 1e 83 46 ..%.k$.I2..F 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'IV used (transmitted)' (0 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'additional data used for AEAD' (5 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 17 03 03 00 20 .... 09/18/25 14:44:28 MBEDTLS3: 0x26d0760: before encrypt: msglen = 16, including 0 bytes of padding 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'after encrypt: tag' (16 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 40 2c ca 66 7b 6d e6 19 cc f7 62 17 93 d6 8f 6f @,.f{m....b....o 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= encrypt buf 09/18/25 14:44:28 MBEDTLS3: 0x26d0760: output record: msgtype = 23, version = [3:3], msglen = 32 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: dumping 'output record sent to network' (37 bytes) 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0000: 17 03 03 00 20 b3 f3 9b cb ae c2 01 48 c3 45 43 .... .......H.EC 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0010: 5f ef 89 a6 c7 40 2c ca 66 7b 6d e6 19 cc f7 62 _....@,.f{m....b 09/18/25 14:44:28 MBEDTLS4: 0x26d0760: 0020: 17 93 d6 8f 6f ....o 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => flush output 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: message length: 37, out_left: 37 09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: Written at offset 1150 #################### [BEGIN] Raw Data (37 bytes): \27\3\3\0 \263\363\233\313\256\302\1H\303EC_\357\211\246\307@,\312f{m\346\31\314\367b\27\223\326\217o\ #################### [_END_] Raw Data 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: ssl->f_send() returned 37 (-0xffffffdb) 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= flush output 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= write record 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= send alert message 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= write close notify 09/18/25 14:44:28 TRACE: MbedTlsClose(0x26d0760): Leave(0) 09/18/25 14:44:28 TRACE: MbedTlsDelete(0x26d0760): Enter 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: => free 09/18/25 14:44:28 MBEDTLS2: 0x26d0760: <= free 09/18/25 14:44:28 TRACE: MbedTlsDelete(0x26d0760): Leave 09/18/25 14:44:28 SSOCK#1000[3]@18.205.36.254:443: Closing (in: 24398 bytes, out: 1187 bytes) 09/18/25 14:44:28 Closing connection 09/18/25 14:44:28 Completed successfully 09/18/25 14:44:28 TRACE: CORE_SetLOG(0x26cb ``` We think that the remote closing the TCP connection without sending some sort of a TLS message that it's going to do so (an alert?) beforehand somehow upsets GNUTLS, but we don't know much about the intricacies of TLS and would really appreciate if you could take a look as to why GNUTLS can't handle the request above. Thank you. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739 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 Sep 19 10:59:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 08:59:53 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: Issue was closed by Alexander Sosedkin Issue #1739: https://gitlab.com/gnutls/gnutls/-/issues/1739 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739 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 Sep 19 11:00:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 09:00:20 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2763354889 > We think that the remote's closing its sending side of the TCP connection without using some sort of a TLS message (an alert?) beforehand that it's about to do so, somehow upsets GNUTLS. A solid hypothesis, if only there was some quick way to check it... TLS 1.3 specification section titled "Closure Alerts" is here: https://datatracker.ietf.org/doc/html/rfc8446#section-6.1, and here's one for TLS 1.2: https://datatracker.ietf.org/doc/html/rfc5246#section-7.2.1, trivially reachable from [what I get as the first google result for "how are tls connections closed"](https://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify). > The client and the server must share knowledge that the connection is > ending in order to avoid a truncation attack. > > ... > > Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. Case closed. > But we don't know much about the intricacies of TLS and would really appreciate if you could take a look as to why GNUTLS can't handle the request above. It can. It'll then rightfully report the insecure protocol violation by the other peer to whatever code is using gnutls. The gnutls support mailing list is [gnutls-help at lists.gnutls.org](https://lists.gnutls.org/mailman/listinfo/gnutls-help). This is a bugtracker for issues in gnutls, and nothing in your report suggests gnutls misbehaving. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2763354889 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 Sep 19 11:14:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 09:14:07 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2763391627 Approving reluctantly because of insufficient test coverage. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2763391627 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 Sep 19 11:14:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 09:14:10 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request !2018 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-provider-followup2 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- 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 Sep 19 16:02:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 14:02:33 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: alavrentiev commented: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764353034 Thank you for your reply! > and nothing in your report suggests gnutls misbehaving. The other TLS implementations (curl, lwp-request and mbedTLS included) process the request without throwing any errors. GNUTLS behavior is drastically different (and fussy). Even though there was no "close_notify" received, there was no outstanding unprocessed input at the time of the EOF, either. So instead of the generic "closed too early" error, GNUTLS could have used some special error code that could help distinguish this corner case condition. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764353034 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 Sep 19 16:16:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 14:16:25 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764397473 I don't think it is possible to tell a benign EOF from an attacker causing an early connection closure. I believe GnuTLS behaviour is correct here, and that this is a security problem in mbedTLS and/or how it is used in curl. Early connection aborts without proper server closure is a serious error condition, and should be reported as such. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764397473 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 Sep 19 16:41:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 14:41:53 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: alavrentiev commented: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764483021 @jas: I wasn't saying that GNUTLS should have returned all-clear. I said it could have used a different error code that tells apart the "broken without any pending input" from "broken in the middle" kind of situation. Right now, it's impossible to tell "how bad" the abrupt termination was. Even though I understand (from reading the provided links to the standard and the discussion) that a bare EOF without "close-notify" is a serious protocol error, regardless. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764483021 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 Sep 19 18:07:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 16:07:34 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764724851 I think it is technically impossible to tell those two situations apart, and that is also why the specification mandates that the alert has to be sent, so that recipient knows it has reached EOF. Some TLS implementations historically just ignored this error case, but that is a security problem. How does OpenSSL behave in this situation? Or some other TLS library. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764724851 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 Sep 19 18:56:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Sep 2025 16:56:18 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: alavrentiev commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764864125 Thank you @jas for your explanation! Unfortunately, we don't use OpenSSL in our projects (which appear to fail with the above). We do use `mbedTLS`, though, and it seems to ignore the protocol violation just as you say. We also use `curl` and it behaves the same as `mbedTLS` (not sure if it's built on top of that library). The same behavior is observed with `lwp-request` (it seems to be `perl`-based, but again I'm unsure what's the underlying TLS implementation). So we had a 3 to 1 situation, which to us looked like a GNUTLS bug -- and which is why I filed this bug report, even though I had a hunch that it might be related to the connection termination. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2764864125 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 Sep 20 03:37:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 20 Sep 2025 01:37:01 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2765691177 Thank you for the review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018#note_2765691177 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 Sep 20 03:37:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 20 Sep 2025 01:37:01 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11-provider: rework to share the code with the existing PKCS#11 support (!2018) In-Reply-To: References: Message-ID: Merge request !2018 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-provider-followup2 to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2018 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 Sep 21 10:02:13 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 21 Sep 2025 08:02:13 +0000 Subject: [gnutls-devel] GnuTLS | Inconsistent subject name processing results (#1740) References: Message-ID: Jasper Sinclair created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1740 ## Description of problem: Hello, I am a new explorer. For two subject names that differ only in capitalization.According to the?X509 RFC,?section 4.1.2.6:Conforming implementations shall perform a case-insensitive exact match when comparing domainComponent attributes in distinguished names.openssl shows them as the same. gnutls also showed them as different.I have provided the use case and script in the attachment. [x509_name_cmp (1).zip](/uploads/c18c036e80dd0bd382011257b2b242ed/x509_name_cmp__1_.zip) ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one?gcc -o to-gnutls to-gnutls.c $(pkg-config --cflags --libs gnutls) * two?./to-gnutls ## Actual results: inconsistent output. ## Expected results: Consistent output. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1740 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 Sep 21 12:58:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 21 Sep 2025 10:58:49 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS error at the end of connection (#1739) In-Reply-To: References: Message-ID: Andreas Metzler commented: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2766600140 Is this usage scenario perhaps similar to the SMTP one? There the big providers simply take done the connection after SMTP QUIT without clean TLS shutdown. Which afaiu is fine from a security standpoint but also make GnuTLS whine. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1739#note_2766600140 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 Sep 24 06:37:13 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 24 Sep 2025 04:37:13 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Instrument crypto-auditing probes (!2019) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2019 Project:Branches: dueno/gnutls:wip/dueno/usdt2 to gnutls/gnutls:master Author: Daiki Ueno This adds USDT probes for crypto-auditing[1], which enables to monitor cryptographic operations at nearly zero cost through eBPF. The probes are defined with the helper library called crau[2], bundled as a copylib. 1. https://github.com/latchset/crypto-auditing/ 2. https://github.com/ueno/crau ## 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/2019 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 Sep 25 07:24:14 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Sep 2025 05:24:14 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!2020) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020 Project:Branches: dueno/gnutls:wip/alistair/key-update to gnutls/gnutls:master Author: Daiki Ueno This is a clone of !1965 for CI purposes. * tls13/key_update: Expose a manual KeyUpdate function As part of supporting KeyUpdate in ktls-utils and NVMe-OF we need to trigger an update of the local keys after the kernel has received a KeyUpdate message. This patch creates a new gnutls_handshake_update_receiving_key() function that allows updating the local keys without sending any KeyUpdate requests. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [x] Any issues marked for closing are addressed * [x] There is a test suite reasonably covering new functionality or modifications * [x] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [x] This feature/change has adequate documentation added * [x] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020 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 Sep 25 08:40:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Sep 2025 06:40:53 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!2020) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020#note_2776756342 Merging without approval, as the original MR has been reviewed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020#note_2776756342 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 Sep 25 08:41:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Sep 2025 06:41:01 +0000 Subject: [gnutls-devel] GnuTLS | tls13/key_update: Expose a manual KeyUpdate function (!2020) In-Reply-To: References: Message-ID: Merge request !2020 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020 Project:Branches: dueno/gnutls:wip/alistair/key-update to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2020 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 Sep 25 21:20:54 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Sep 2025 19:20:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls certificate with duplicates in the chain is rejected (#1741) References: Message-ID: Sergey Koposov created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1741 Hi, ## Description of problem: The certificate with duplicates in the chain is rejected by gnutls (but is accepted by openssl and other libraries). The issue arose when evolution email client started to complain about 'unacceptable tls certificate' when trying to authenticate for my email. This lead me to investigate and run: ``` $ gnutls-cli edadfed.ed.ac.uk Processed 146 CA certificate(s). Resolving 'edadfed.ed.ac.uk:443'... Connecting to '129.215.67.169:443'... - Certificate type: X.509 - Got a certificate list of 23 certificates. - Certificate[0] info: - subject `CN=edadfed.ed.ac.uk,O=The University of Edinburgh,L=Edinburgh,C=GB', issuer `CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US', serial 0x0d296cf890eebdccb272d452d54ff742, RSA key 2048 bits, signed using RSA-SHA256, activated `2025-08-20 00:00:00 UTC', expires `2026-08-19 23:59:59 UTC', pin-sha256="t6K+8+rkiqVzq9PrgQhq3zleQFNGA2zGshvNCwRcYI4=" Public Key ID: sha1:bc67d663290cece53fccc2da4a8339c81140be98 sha256:b7a2bef3eae48aa573abd3eb81086adf395e405346036cc6b21bcd0b045c608e Public Key PIN: pin-sha256:t6K+8+rkiqVzq9PrgQhq3zleQFNGA2zGshvNCwRcYI4= - Certificate[1] info: - subject `CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US', issuer `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0cf5bd062b5602f47ab8502c23ccf066, RSA key 2048 bits, signed using RSA-SHA256, activated `2021-03-30 00:00:00 UTC', expires `2031-03-29 23:59:59 UTC', pin-sha256="Wec45nQiFwKvHtuHxSAMGkt19k+uPSw9JlEkxhvYPHk=" .... - Certificate[21] info: - subject `CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US', issuer `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0cf5bd062b5602f47ab8502c23ccf066, RSA key 2048 bits, signed using RSA-SHA256, activated `2021-03-30 00:00:00 UTC', expires `2031-03-29 23:59:59 UTC', pin-sha256="Wec45nQiFwKvHtuHxSAMGkt19k+uPSw9JlEkxhvYPHk=" - Certificate[22] info: - subject `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', issuer `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x033af1e6a711a9a0bb2864b11d09fae5, RSA key 2048 bits, signed using RSA-SHA256, activated `2013-08-01 12:00:00 UTC', expires `2038-01-15 12:00:00 UTC', pin-sha256="i7WTqTvh0OioIruIfFR4kMPnBqrS2rdiVPl/s2uC/CY=" - Could not verify certificate (err: Some constraint limits were reached.) *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. ``` It is my understanding the problem is that the same two certificates are repeated 11 times in the chain. It is clearly the problem on the server side, but openssl does not seem to have issues with it (and other clients either). I have seen issue #1335 which seemed to me like it should have fixed the issue with certificate marked invalid if there are duplicates in the chain in 3.8.x branch, but it does not seem to be the case. I am not really an ssl expert if it is really a bug on the gnutls side or it is just strict, but from a user standpoint it would be nice not to reject this certificate. Also if I do --save-cert and certtool --verify it does not complain. ## Version of gnutls used: 3.8.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL): Ubuntu ## How reproducible: Steps to Reproduce: * $ gnutls-cli edadfed.ed.ac.uk ## Actual results: - Could not verify certificate (err: Some constraint limits were reached.) \*\*\* PKI verification of server certificate failed... \*\*\* Fatal error: Error in the certificate. ## Expected results: The certificate should be accepted Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1741 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 Sep 29 05:12:13 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Sep 2025 03:12:13 +0000 Subject: [gnutls-devel] GnuTLS | session: Allow packing and restoring an entire session (!2021) References: Message-ID: Alistair Francis created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/2021 Project:Branches: alistair23/gnutls:alistair/session-pack to gnutls/gnutls:master Author: Alistair Francis As part of the work to support KeyUpdate in ktls-utils and the Linux kernel we need to be able to [save and restore the gnutls session](https://lore.kernel.org/kernel-tls-handshake/49a61a63-db9a-42cd-afa9-3f177400bd86 at suse.de/T/#ma9fb251a756fe427bc474f113572abc5fbe8ddab) in the kernel keyring. Basically ktls-utils will use gnutls for the handshake then hand the keys and connection information off to the kernel for the kernel to take over. At this point gnutls needs to be able to save it's state in a buffer for use later. This series allows that by saving the gnutls state in a buffer and then allowing us to restore that state and then update keys later on. This requires saving a lot more information then gnutls currently does, including security_parameters, TLS keys and record_parameters. We also need to save the information even if a handshake hasn't completed yet. This requires https://gitlab.com/gnutls/gnutls/-/merge_requests/1968 ## Checklist * [X] Commits have `Signed-off-by:` with name/author being identical to the commit author * [X] Code modified for feature * [X] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [X] 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/2021 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 Sep 29 06:59:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Sep 2025 04:59:25 +0000 Subject: [gnutls-devel] GnuTLS | Look for /usr/etc/crypto-policies if there is no /etc/crypto-policies (#1742) References: Message-ID: Ben Creasy created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1742 I think there is an emerging convention to look to `/usr/etc` for package-provided default configuration and `/etc/` for local administrator overrides - see https://en.opensuse.org/openSUSE:Packaging_UsrEtc Obviously there's no requirement to fall back to `/usr/etc` but it can be a convenience for users to make it more clear to where they've overridden package defaults. With no `/etc/crypto-policies` I see this: ``` ? sudo mv /etc/{crypto-policies,crypto-policies2} [sudo] password for ben: ben in dotfiles on ? master [$!?] took 2s ? GNUTLS_DEBUG_LEVEL=3 gnutls-cli --priority "SYSTEM" --print-cert raw.githubusercontent.com:443 2>&1 | head -20 gnutls[2]: Enabled GnuTLS 3.8.10 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: unable to access: /etc/crypto-policies/back-ends/gnutls.config: 2 Syntax error at: SYSTEM Processed 388 CA certificate(s). Resolving 'raw.githubusercontent.com:443'... Connecting to '185.199.111.133:443'... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1742 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: