From gnutls-devel at lists.gnutls.org Mon Nov 1 17:18:07 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Nov 2021 16:18:07 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented: @asosedkin sorry, after second thought, looks like the changes in !1482 could be simpler and robuster if we move the locking logic to the caller. So I reverted the previous MR and added the fix on top of it. Could you take a look? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720129431 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 Nov 1 18:48:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Nov 2021 17:48:45 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200779 > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); I don't understand in general: why have it inside the loop and not before it? It's not like there the loop duration is meaningfully long, and then if somebody manages to update the config in-between reloadings, I'm not sure I prefer switching to a new version mid-loop. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200785 > #include > > +/* Lock for reading and updating the following global variables prefixed with Is it time to group them into a struct? If we aim for consistency between reading/updating them as a group, that could make it more explicit. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200789 > + /* This requires a lock so there are no inconsistencies in system_wide_* > + * loaded from the config file. */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); Mild: I'd prefer locking inside the function or in an extra wrapper around it if it's inconvenient to overhaul its flow. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720200794 > void _gnutls_unload_system_priorities(void) We deliberately don't lock in this one or `_clear_default_system_priority` because ensuring thread safety is on the caller of `gnutls_global_deinit`, right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 1 19:12:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Nov 2021 18:12:58 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720233469 > **/ > const char *gnutls_get_system_config_file(void) > { > - if (system_wide_priority_strings_init) > + if (system_wide_priority_strings) What's the purpose of this check and returning `NULL`? `system_priority_file` is set early and guarded by `global_init_mutex`, so, without locking, this makes it a "filename of the system wide configuration loaded or currently being loaded by the library; NULL if loading hasn't been attempted yet". Lock and turn into "filename of loaded; NULL if not yet"? Stop returning NULL? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720233469 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 Nov 1 19:14:02 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Nov 2021 18:14:02 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: > This variable was only for tracking whether `system_wide_priority_strings` is set, which can be simply a NULL check. I don't like f243f561 in isolation, as `system_wide_priority_strings` is neither constructed nor deinitialized atomically, and it's only locking that comes in the next commit that gives `!!system_wide_priority_strings` a safe enough meaning. I wouldn't mind them merged into one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720234506 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 Nov 2 09:32:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 08:32:46 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720721773 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); Let me add a bit of the context of this change: in the previous version, we had mutex lock/unlock in `_gnutls_update_system_priorities`. This was not sufficient, because in the following line we have a read access with `_name_val_array_value`. So this is the approach to keep the critical section minimal. On the other hand, I tend to think this should be protected with an RW lock instead of mutex (because there could be multiple reader of the global variables, while there should be a single writer). The current GnuTLS code base doesn't have any abstraction of RW lock, but maybe we could import `pthread-rwlock` from Gnulib. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720721773 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 Nov 2 12:17:52 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 11:17:52 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720926259 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); Sorry, I guess I've misclicked and the question turned out real vague. It was supposed to be "why have `_gnutls_update_system_priorities` inside the loop"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720926259 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 Nov 2 12:58:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 11:58:25 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720970920 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); The motivation is to make the critical section smaller and more obvious. I agree that having a lock outside the loop would increase performance, though I'd say the usage of mutex here is cheap enough. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_720970920 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 Nov 2 14:10:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 13:10:45 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721050944 > void _gnutls_unload_system_priorities(void) Yes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721050944 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 Nov 2 14:13:15 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 13:13:15 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721053767 > **/ > const char *gnutls_get_system_config_file(void) > { > - if (system_wide_priority_strings_init) > + if (system_wide_priority_strings) Yes, always return non-NULL value sounds better. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721053767 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 Nov 2 14:44:00 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 13:44:00 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721095540 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); No-no-no. Forget locking for a minute, what do we lose if we `_gnutls_update_system_priorities` only once before the loop? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721095540 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 Nov 2 15:16:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 14:16:25 +0000 Subject: [gnutls-devel] GnuTLS | FIPS: Missing self-tests for SHAKE256 (#1284) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1284: https://gitlab.com/gnutls/gnutls/-/issues/1284 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1284 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 Nov 2 15:16:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 14:16:25 +0000 Subject: [gnutls-devel] GnuTLS | FIPS: Missing self-tests for SHAKE256 (#1284) In-Reply-To: References: Message-ID: Daiki Ueno commented: The current self-tests are sufficient, as the IG mentions "one of the functions defined in FIPS 202". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1284#note_721146609 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 Nov 2 15:54:17 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 14:54:17 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721209729 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); That's a good point and I haven't thought about it; thanks. If we move the call out of the loop, I suppose the code will look like: ```c // lock _gnutls_update_system_priorities(); do { ... p = name_val_array_value(system_wide_priority_strings, ss, ss_len); ... // use p } while (ss && ret == NULL); // unlock ``` I think this expands the critical section unnecessarily. If we could use RW lock, it could be written like: ```c // wrlock _gnutls_update_system_priorities(); // unlock do { ... // rdlock p = name_val_array_value(system_wide_priority_strings, ss, ss_len); ... // use p // unlock } while (ss && ret == NULL); ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721209729 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 Nov 2 16:56:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 15:56:40 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721296096 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); I hope that all the heavy lifting here is localized in `_gnutls_update_system_priority` and is conditioned on actually reading the file after failing the mtime stat check; and then everyone has to wait no matter what. Provided no actual reload is necessary, it'll be just a stat call we wrlock for, and the rest shouldn't really meaningfully be long, just a bit of syscall-free string crunching, right? So, I see little benefit in scenario 2 over 1: we unconditionally wrlock in both and the scope of wrlocking isn't much different. Now, one could keep advancing in your suggested direction and narrow wrlocking further to also exclude the mtime check: ``` // rdlock inside _gnutls_update_system_priorities { if (/* mtime_check() */) return; // upgrade rdlock to wrlock // init check // heavy lifting // unlock } do { // rdlock // access // unlock } ``` that allows for some executions to attempt no wrlocks, but will the gains between 1 and 3 be worth the complexity? I doubt it. If it were on me, I'd probably leave a note saying `TODO if somebody complains about the performance: locking could be narrowed to wrlocking for the part past the mcheck` and move on for now =) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721296096 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 Nov 2 17:16:17 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 16:16:17 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721319877 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); One minor thing on excluding the mtime check from the wrlock section is that, when there is a contention, it would require extra `stat` syscall after obtaining wrlock (because the timestamp may have changed while waiting). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721319877 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 Nov 2 18:03:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Nov 2021 17:03:19 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721370433 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); Not necessarily? The current guarantee is "load a config no older than the moment we invoke the function", what would that change upgrade it to? I'd propose (getting progressively more frivolous with pseudocode): ``` stat(&mtime); rdlock(); if (init_indicator && mtime == last_mtime) { unlock(); return; } wrlock(); if (mtime == last_mtime) { unlock(); return; } // other thread beat us to loading with the same mtime ... last_mtime = mtime; unlock(); ``` which is a middle-ground that'd still catch some updates during mass-waiting (just not the ones that happened after the last updater was started), yet stick to a single stat call. All this talk makes me wonder what software does and does not actually bother with atomically replacing gnutls system configs =) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721370433 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 Nov 3 10:34:56 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 03 Nov 2021 09:34:56 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721950369 > * allow it to be updated without restarting > * all applications > */ > + GNUTLS_STATIC_MUTEX_LOCK(system_wide_config_mutex); > _gnutls_update_system_priorities(); OK, I've rewritten it along these lines; thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721950369 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 Nov 3 10:35:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 03 Nov 2021 09:35:58 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721951629 > > #include > > +/* Lock for reading and updating the following global variables prefixed with Yeah, that's in line with the upcoming [refactoring](https://gitlab.com/gnutls/gnutls/-/merge_requests/1427/diffs?commit_id=d89f2c32b6e10de277c2a8c2fef9fdf3e06a6ef6). Updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_721951629 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 Nov 3 18:59:32 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 03 Nov 2021 17:59:32 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674749 > + /* Another thread has updated the system wide config while upgrading to > + * write lock. */ > + if (system_priority_last_mod >= sb.st_mtime) { Previously we haven't depended on mtime monotonicity, now we do. Moving a file or restoring from a backup could be changes that jump back in mtime that we would better still pick up. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674752 > + /* Another thread has updated the system wide config while upgrading to > + * write lock. */ > + if (system_priority_last_mod >= sb.st_mtime) { Here we implicitly use `system_priority_last_mod` as a flag of the config being loaded. I'd either check `system_priority_file_loaded` as well for clarity or drop `system_priority_file_loaded` and leave just `system_priority_last_mod` if it's possible and convenient. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674753 > + } > + > + _name_val_array_clear(&system_wide_config.priority_strings); Minor: I'd clear `system_priority_file_loaded` even if there are no immediate benefits. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674754 > * > - * Returns: a constant pointer to the config file loaded, or %NULL if none > + * Returns: a constant pointer to the config file I'd extend to `file path`, maybe. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674758 > > + /* This requires a lock so there are no inconsistencies in system_wide_* > + * loaded from the config file. */ Nit: not updated since `system_wide_config` grouping has happened. -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_722674768 > - * file loaded by the library. The returned pointer is valid > - * until the library is unloaded. > + * file to be loaded by the library. Why remove this sentence? That'd restrict our potential future maneuvers, while the current limitation is sensible. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 4 11:45:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Nov 2021 10:45:46 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_723315217 I think yes. Older versions of the TCG spec seem to have allowed salt size == digest size for unrestricted keys with sign operation, but the latest document doesn't. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_723315217 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 Nov 4 11:46:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Nov 2021 10:46:05 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: All discussions on merge request !1460 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 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 Nov 4 11:48:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Nov 2021 10:48:19 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented: I'm going to merge this soon; if there is anything that should be done before merge, please speak up :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_723321187 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 Nov 4 12:36:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Nov 2021 11:36:37 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: David Woodhouse commented: As long as you have ongoing regression testing which validates interop with the engines and with OpenConnect, I'm happy. The swtpm tests in OpenConnect can help with that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_723379880 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 Nov 4 16:14:48 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Nov 2021 15:14:48 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_723765000 > * gnutls_get_system_config_file: > * > * Returns the filename of the system wide configuration > - * file loaded by the library. The returned pointer is valid > - * until the library is unloaded. > + * file to be loaded by the library. As unloading is pretty rare occasions, I would rather not mention the possibility here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_723765000 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 Nov 5 08:04:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 07:04:06 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_724831636 > + if (system_priority_file_loaded && > sb.st_mtime == system_priority_last_mod) { > _gnutls_debug_log("cfg: system priority %s has not changed\n", > system_priority_file); > goto out; > } > > - _name_val_array_clear(&system_wide_priority_strings); > - system_wide_priority_strings_init = 0; > + GNUTLS_STATIC_RWLOCK_UNLOCK(system_wide_config_rwlock); > + > + GNUTLS_STATIC_RWLOCK_WRLOCK(system_wide_config_rwlock); > + > + /* Another thread has updated the system wide config while upgrading to > + * write lock. */ > + if (system_priority_last_mod >= sb.st_mtime) { I have no idea what we can do for those cases; suggestions? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_724831636 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 Nov 5 11:15:41 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 10:15:41 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_725023497 > + if (system_priority_file_loaded && > sb.st_mtime == system_priority_last_mod) { > _gnutls_debug_log("cfg: system priority %s has not changed\n", > system_priority_file); > goto out; > } > > - _name_val_array_clear(&system_wide_priority_strings); > - system_wide_priority_strings_init = 0; > + GNUTLS_STATIC_RWLOCK_UNLOCK(system_wide_config_rwlock); > + > + GNUTLS_STATIC_RWLOCK_WRLOCK(system_wide_config_rwlock); > + > + /* Another thread has updated the system wide config while upgrading to > + * write lock. */ > + if (system_priority_last_mod >= sb.st_mtime) { I'd rather strongly prefer we revert to the previous strict `!=` check and thus end up loading what's chronologically read from disk later, no matter what its relative mtime jump sign was. I think this leads to the least surprising behaviour possible. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_725023497 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 Nov 5 13:48:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 12:48:58 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_725187640 > + if (system_priority_file_loaded && > sb.st_mtime == system_priority_last_mod) { > _gnutls_debug_log("cfg: system priority %s has not changed\n", > system_priority_file); > goto out; > } > > - _name_val_array_clear(&system_wide_priority_strings); > - system_wide_priority_strings_init = 0; > + GNUTLS_STATIC_RWLOCK_UNLOCK(system_wide_config_rwlock); > + > + GNUTLS_STATIC_RWLOCK_WRLOCK(system_wide_config_rwlock); > + > + /* Another thread has updated the system wide config while upgrading to > + * write lock. */ > + if (system_priority_last_mod >= sb.st_mtime) { Sorry, that'd be `==`, not `!=`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_725187640 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 Nov 5 14:00:21 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 13:00:21 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: All discussions on merge request !1483 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 5 14:03:14 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 13:03:14 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Merge request !1483 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 Project:Branches: dueno/gnutls:wip/dueno/system_wide_priority_strings_init to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 5 14:09:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 13:09:44 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks for the review and suggestions! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483#note_725209183 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 Nov 5 14:09:50 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 13:09:50 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Merge request !1483 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 Project:Branches: dueno/gnutls:wip/dueno/system_wide_priority_strings_init to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 5 15:08:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Nov 2021 14:08:19 +0000 Subject: [gnutls-devel] GnuTLS | priority: rework config reloading logic and locking (!1483) In-Reply-To: References: Message-ID: Merge request !1483 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 Project:Branches: dueno/gnutls:wip/dueno/system_wide_priority_strings_init to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1483 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 Nov 7 10:58:47 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Nov 2021 09:58:47 +0000 Subject: [gnutls-devel] GnuTLS | Problematic CSR (self-signature verification fails) (#1287) References: Message-ID: Adriano Santoni created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1287 Hello, I am not reporting a bug, I think, but sharing a reasoning and requesting confirmation or an alternative explanation. The attached CSR does not verify with **certtool**: ``` $ certtool --crq-info --infile Self signature: FAILED ``` I suppose this result is correct, in that - based on my investigations and my understanding of RC2986 - the signature in the attached CSR seems to have been computed over its certificationRequestInfo element without first DER-encoding it (as per RFC2986), which means having computed it over the wrong data. In fact, the attached CSR is not already DER-encoded (it contains an unordered multi-value RDN in the Subject field), therefore DER encoding the certificationRequestInfo element yields different bytes than those found in the CSR itself. Hence the FAILED result, if my reasoning is correct. I am not fully sure of my theory, though, and there could be other explanations, so I'd appreciate some GnuTLS developer(s) to confirm it or refute it. [problematic-csr.pem](/uploads/fc76184b01038e828238299558ef12ed/problematic-csr.pem) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1287 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 Nov 8 15:43:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Nov 2021 14:43:54 +0000 Subject: [gnutls-devel] GnuTLS | Problematic CSR (self-signature verification fails) (#1287) In-Reply-To: References: Message-ID: Daiki Ueno commented: Given the failure occurs at the very low level of signature verification (by looking at the code pointed by `-d` output), I can't tell much without knowing how the signature was made (including which private key was used). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1287#note_726856425 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 Nov 8 18:50:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Nov 2021 17:50:53 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented: @dwmw2 could you instruct me how I can run the swtpm tests in OpenConnect against locally installed GnuTLS? With this [patch](/uploads/a1278991cb21641df9f817304380d57a/gnutls-tpm2.diff), should the following steps be sufficient? ```console $ cd ../gnutls $ ./configure --prefix=build --disable-doc --disable-guile $ make && make install $ cd ../openconnect $ patch -p1 < gnutls-tpm2.diff $ PKG_CONFIG_PATH=$PWD/../gnutls/build/lib/pkgconfig ./configure $ make $ make check TESTS=auth-swtpm ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_727095286 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 Nov 8 19:13:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Nov 2021 18:13:05 +0000 Subject: [gnutls-devel] GnuTLS | tests: stop passing and using $abs_top_builddir (!1484) References: Message-ID: Alexander Sosedkin created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 Project:Branches: asosedkin/gnutls:abs-top-builddir-fix to gnutls/gnutls:master Author: Alexander Sosedkin Add a description of the new feature/bug fix. Reference any relevant bugs. `$abs_top_builddir` has been used all across tests' subdirectories (through tests/scripts/common) but has only been defined for tests/suite/ ones. Since: * it's the only user for it inside tests/ * nothing comes to mind on why it has to be absolute * it's been expanding to nothing and nobody complained it should be safe to switch over to a much more widely defined `$top_builddir` and drop all `$abs_top_builddir` mentions from tests/ altogether. ## 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) * [x] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1484 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 Nov 8 19:30:26 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Nov 2021 18:30:26 +0000 Subject: [gnutls-devel] GnuTLS | tests: stop passing and using $abs_top_builddir (!1484) In-Reply-To: References: Message-ID: Daiki Ueno commented: The reason we use absolute paths in common.sh is that, afair, the shell functions might be called after changing the working directory. This might not be a problem with the current setting, but I guess we would need to document the limitation in the script if we switch to use relative path. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484#note_727126322 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 Nov 8 19:39:22 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Nov 2021 18:39:22 +0000 Subject: [gnutls-devel] GnuTLS | tests: stop passing and using $abs_top_builddir (!1484) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Oh. OK, please pick an option: 1. restore `$abs_top_builddir` and plumb it to all currently existing test subdirs 2. restore `$abs_top_builddir` to just those test subdirs that currently rely on it indirectly 3. resolve and cache abspath at script-sourcing time; leave a comment prescribing to source it before changing directory 4. use `$top_builddir` (current MR's state) + leave a comment in the sourced file to not change directory when calling functions or propose more variants. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484#note_727132104 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 Nov 9 10:51:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 09:51:53 +0000 Subject: [gnutls-devel] GnuTLS | tests: stop passing and using $abs_top_builddir (!1484) In-Reply-To: References: Message-ID: Daiki Ueno commented: I have a feeling that tests generally need absolute path so my slight preference is (1). As for the specific issue (i.e., reserve_port), it might make sense to consider using [socket_wrapper](https://cwrap.org/socket_wrapper.html). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484#note_727686771 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 Nov 9 10:54:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 09:54:40 +0000 Subject: [gnutls-devel] libtasn1 | gtk-doc API indexes missing when built with gtk-doc from debian bullseye (#35) In-Reply-To: References: Message-ID: Issue was closed by Simon Josefsson via merge request !83 (https://gitlab.com/gnutls/libtasn1/-/merge_requests/83) Issue #35: https://gitlab.com/gnutls/libtasn1/-/issues/35 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/35 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 Nov 9 10:54:39 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 09:54:39 +0000 Subject: [gnutls-devel] libtasn1 | doc: Improve GTK-DOC manual. Closes: #35. (!83) In-Reply-To: References: Message-ID: Merge request !83 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/83 Branches: tmp-gtkdoc-fixes to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/83 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 Nov 9 12:36:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 11:36:05 +0000 Subject: [gnutls-devel] libtasn1 | Tools in src/ don't print final newline (#37) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/libtasn1/-/issues/37 Output: ``` jas at latte:~/src/libtasn1$ src/asn1Coding -h 2>&1|tail -1 Report bugs to help-libtasn1 at gnu.orgjas@latte:~/src/libtasn1$ ``` It would be nice to restore use of the gnulib progname module for the verbatim texts, to also make Debian's --with-packer stuff work again and provide better --version outputs. Compare Debian stretch output: ``` root at bull:~# asn1Parser |tail -4 Report bugs to: help-libtasn1 at gnu.org Report Debian bugs to: http://bugs.debian.org/ GNU Libtasn1 home page: General help using GNU software: root at bull:~# ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/37 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 Nov 9 13:00:18 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 12:00:18 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes (!84) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 Branches: tmp-buildfixes to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 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 Nov 9 13:00:55 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 12:00:55 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes (!84) In-Reply-To: References: Message-ID: Merge request !84 was scheduled to merge after pipeline succeeds by Simon Josefsson Merge request url: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 Branches: tmp-buildfixes to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 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 Nov 9 13:26:56 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 12:26:56 +0000 Subject: [gnutls-devel] GnuTLS | Problematic CSR (self-signature verification fails) (#1287) In-Reply-To: References: Message-ID: Adriano Santoni commented: It doesn't seem to me particularly useful to know how it was generated, however it was generated with the PKI.js library. I have generated another one (attached here), this time also keeping the private key (also attached); with this latter, it is easy to see that the signature on the CSR is cryptographically correct but was computed over the certRequestInfo element "AS IS" (i.e. as found in the CSR), ignoring that the Subject within is not DER-encoded. [problem-csr-20211109.key](/uploads/4d7949f050d34ca7bdd9a97901fc9939/problem-csr-20211109.key) [problem-csr-20211109.req](/uploads/d8ce5abd0fe173a6ea68c9047324e84a/problem-csr-20211109.req) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1287#note_727888366 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 Nov 9 13:43:10 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 12:43:10 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes (!84) In-Reply-To: References: Message-ID: Merge request !84 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 Branches: tmp-buildfixes to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/84 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 Nov 9 15:17:07 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 14:17:07 +0000 Subject: [gnutls-devel] libtasn1 | Update gnulib and use it in src/. (!85) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 Branches: tmp-src-gnulib to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 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 Nov 9 15:17:26 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 14:17:26 +0000 Subject: [gnutls-devel] libtasn1 | Update gnulib and use it in src/. (!85) In-Reply-To: References: Message-ID: Merge request !85 was scheduled to merge after pipeline succeeds by Simon Josefsson Merge request url: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 Branches: tmp-src-gnulib to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 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 Nov 9 15:18:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 14:18:46 +0000 Subject: [gnutls-devel] libtasn1 | Tools in src/ don't print final newline (#37) In-Reply-To: References: Message-ID: Issue was closed by Simon Josefsson via commit d24fb4c02bf9596ea878658446840d056542bbd4 Issue #37: https://gitlab.com/gnutls/libtasn1/-/issues/37 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/37 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 Nov 9 15:18:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 14:18:46 +0000 Subject: [gnutls-devel] libtasn1 | Update gnulib and use it in src/. (!85) In-Reply-To: References: Message-ID: Merge request !85 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 Branches: tmp-src-gnulib to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/85 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 Nov 9 17:03:48 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:03:48 +0000 Subject: [gnutls-devel] libtasn1 | Doc fixes. Version handling fixes. (!86) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 Branches: tmp-doc-fixes to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 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 Nov 9 17:05:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:05:37 +0000 Subject: [gnutls-devel] libtasn1 | Doc fixes. Version handling fixes. (!86) In-Reply-To: References: Message-ID: Merge request !86 was scheduled to merge after pipeline succeeds by Simon Josefsson Merge request url: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 Branches: tmp-doc-fixes to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 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 Nov 9 17:06:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:06:19 +0000 Subject: [gnutls-devel] libtasn1 | Doc fixes. Version handling fixes. (!86) In-Reply-To: References: Message-ID: Merge request !86 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 Branches: tmp-doc-fixes to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/86 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 Nov 9 17:43:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:43:06 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes including code indent. (!87) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 Branches: tmp-indent to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 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 Nov 9 17:44:51 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:44:51 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes including code indent. (!87) In-Reply-To: References: Message-ID: Merge request !87 was scheduled to merge after pipeline succeeds by Simon Josefsson Merge request url: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 Branches: tmp-indent to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 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 Nov 9 17:47:36 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Nov 2021 16:47:36 +0000 Subject: [gnutls-devel] libtasn1 | Maintainer fixes including code indent. (!87) In-Reply-To: References: Message-ID: Merge request !87 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 Branches: tmp-indent to master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/87 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 Nov 10 06:49:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 05:49:58 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented: OK, I managed to make the test succeed, with the following change: ```diff diff --git a/tests/auth-swtpm b/tests/auth-swtpm index d1b806c6..fded3753 100755 --- a/tests/auth-swtpm +++ b/tests/auth-swtpm @@ -41,6 +41,8 @@ LD_PRELOAD=libsocket_wrapper.so ${SWTPM_IOCTL} --tcp 127.0.0.1:2322 --load perma LD_PRELOAD=libsocket_wrapper.so ${SWTPM_IOCTL} --tcp 127.0.0.1:2322 -i export TPM_INTERFACE_TYPE=socsim +export GNUTLS_TCTI="mssim:host=127.0.0.1,port=2321" +export GNUTLS_PIN=test # We don't actually *require* either of the startup tools # to be present; we can fall back to killing swtpm and then ``` with: ```console $ PKG_CONFIG_PATH=$PWD/../gnutls/build/lib/pkgconfig LDFLAGS="-Wl,-rpath,$PWD/../gnutls/build/lib" ./configure --htmldir=$PWD/html $ make $ make VERBOSE=1 TESTS=auth-swtpm check ``` Here is the [log](/uploads/0121a65de6069f1a28131e9f246096ea/auth-swtpm.log). For some reason it intermittently fails on my environment with: ```console RROR:esys:src/tss2-esys/api/Esys_RSA_Decrypt.c:102:Esys_RSA_Decrypt() Esys Finish ErrorCode (0x00000101) ``` which I have no idea how to fix. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_728956580 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 Nov 10 08:58:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 07:58:23 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: David Woodhouse commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_729034853 > @dwmw2 could you instruct me how I can run the swtpm tests in OpenConnect against locally installed GnuTLS? > With this patch, should the following steps be sufficient? Yes, that looks sane. Those environment variables would be user-visible though, and I try to avoid having user-visible differences based on how OpenConnect was built. Do I get a callback to *ask* me for a specific PIN if/when it's required? And can I have a function to call with the TCTI settings please? (What I'd actually intended was pulling in just the stuff from openconnect's tests/ directory and running GnuTLS tests on *those* files as your part of your regular regression testing. But certainly as a one-off, running it *in* OpenConnect is a good test!) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_729034853 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 Nov 10 13:24:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 12:24:24 +0000 Subject: [gnutls-devel] GnuTLS | tests: pass $abs_top_builddir more consistently (!1484) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: OK, 180 degree turn, now I simply pass it in more Makefiles. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484#note_729431848 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 Nov 10 13:28:12 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 12:28:12 +0000 Subject: [gnutls-devel] GnuTLS | tests: pass $abs_top_builddir more consistently (!1484) In-Reply-To: References: Message-ID: Merge request !1484 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 Project:Branches: asosedkin/gnutls:abs-top-builddir-fix to gnutls/gnutls:master Author: Alexander Sosedkin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 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 Nov 10 13:28:20 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 12:28:20 +0000 Subject: [gnutls-devel] GnuTLS | tests: pass $abs_top_builddir more consistently (!1484) In-Reply-To: References: Message-ID: Merge request !1484 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 Project:Branches: asosedkin/gnutls:abs-top-builddir-fix to gnutls/gnutls:master Author: Alexander Sosedkin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 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 Nov 10 13:28:31 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Nov 2021 12:28:31 +0000 Subject: [gnutls-devel] GnuTLS | tests: pass $abs_top_builddir more consistently (!1484) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you for the fix! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484#note_729439165 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 Nov 11 07:22:35 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Nov 2021 06:22:35 +0000 Subject: [gnutls-devel] GnuTLS | tests: pass $abs_top_builddir more consistently (!1484) In-Reply-To: References: Message-ID: Merge request !1484 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 Project:Branches: asosedkin/gnutls:abs-top-builddir-fix to gnutls/gnutls:master Author: Alexander Sosedkin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1484 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 Nov 13 13:01:13 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 12:01:13 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732458750 The intermittent failures turned out to be the confusion of emBits (one bit fewer than the modulus). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732458750 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 Nov 13 15:13:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 14:13:19 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732480160 As for PIN, the `GNUTLS_PIN` mentioned above actually has no effect; the application needs to set a callback with `gnutls_privkey_set_pin_function` (or similar). I would leave the TCTI setting API (or any other means) to a separate MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732480160 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 Nov 13 15:13:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 14:13:19 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: All discussions on merge request !1460 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 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 Nov 13 17:09:35 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 16:09:35 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Merge request !1460 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 Project:Branches: dueno/gnutls:wip/dueno/tpm2 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 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 Nov 13 17:09:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 16:09:27 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Daiki Ueno commented: Given the original work is not mine and (informal) reviews have been done, I'm merging this without approval. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732503275 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 Nov 13 18:22:56 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 17:22:56 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/algorithms/ecc.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_732514055 > + } > +} > + > +/** > + * gnutls_ecc_curve_mark_enabled: > + * @curve: is an ECC curve > + * > + * Mark @curve as disabled system wide. This setting can be reverted with > + * gnutls_ecc_curve_mark_enabled(). This only works if the configuration file > + * uses the allowlisting mode. > + * > + * Returns: 0 on success or negative error code otherwise. > + * > + * Since: 3.7.3 > + */ > +int gnutls_ecc_curve_mark_disabled(gnutls_ecc_curve_t curve) The `..._mark_disabled` and `..._mark_enabled` functions introduce a lot of code duplication. Maybe introduce helper functions that take a bool value 'enabled' !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_732514055 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 Nov 13 19:46:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 18:46:23 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: David Woodhouse commented: Thanks for bringing this into GnuTLS! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460#note_732527372 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 Nov 13 20:02:21 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 13 Nov 2021 19:02:21 +0000 Subject: [gnutls-devel] GnuTLS | Cannot export hidden symbol __gnutls_arm_cpuid_s when building on macOS Monterey in M1 machine. (#1288) References: Message-ID: Eduardo Ren? Rodr?guez ?vila created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1288 ## Description of problem: Building `gnutls` 3.7.2 fails on macOS Monterey with error: ... CCLD libgnutls.la
ld: warning: cannot export hidden symbol __gnutls_arm_cpuid_s from accelerated/.libs/libaccelerated.a(aarch64-common.o)
Undefined symbols for architecture arm64:
"_c_isdigit", referenced from:
__asn1_expand_object_id in libminitasn1.a(parser_aux.o)
__asn1_check_identifier in libminitasn1.a(parser_aux.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation) ## Version of gnutls used: 3.7.2 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Tarball downloaded from [gnupg.org](https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/) ## How reproducible: In a Mac M1 with macOS Monterey and using ZSH, follow next steps: Steps to Reproduce: % curl -O https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.2.tar.xz % tar -xvf gnutls-3.7.2.tar.xz % pushd gnutls-3.7.2 % /usr/local/sbin/unbound-anchor -a "/etc/unbound/root.key" % CFLAGS="-m64" CXXFLAGS="-m64" ./configure --prefix=/usr/local --without-p11-kit --with-ncluded-libtasn1 --with-included-unistring % make ## Actual results: ... ld: warning: cannot export hidden symbol __gnutls_arm_cpuid_s from accelerated/.libs/libaccelerated.a(aarch64-common.o)
Undefined symbols for architecture arm64:
"_c_isdigit", referenced from:
__asn1_expand_object_id in libminitasn1.a(parser_aux.o)
__asn1_check_identifier in libminitasn1.a(parser_aux.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation) ## Expected results: Successful compilation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1288 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 Nov 14 08:12:39 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 14 Nov 2021 07:12:39 +0000 Subject: [gnutls-devel] GnuTLS | Port openconnect TPM2 code (!1460) In-Reply-To: References: Message-ID: Merge request !1460 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 Project:Branches: dueno/gnutls:wip/dueno/tpm2 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1460 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 Nov 14 08:16:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 14 Nov 2021 07:16:46 +0000 Subject: [gnutls-devel] GnuTLS | Cannot export hidden symbol __gnutls_arm_cpuid_s when building on macOS Monterey in M1 machine. (#1288) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you for the report. The error looks familiar (as in https://gitlab.com/gnutls/libtasn1/-/issues/28); it has been fixed in a newer libtasn1 release, but the bundled libtasn1 hasn't been updated yet. I suppose the issue would be fixed if you use the libtasn1 release or patch the included libtasn1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1288#note_732598341 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 Nov 14 12:37:01 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 14 Nov 2021 11:37:01 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/algorithms/ecc.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_732633275 > + } > +} > + > +/** > + * gnutls_ecc_curve_mark_enabled: > + * @curve: is an ECC curve > + * > + * Mark @curve as disabled system wide. This setting can be reverted with > + * gnutls_ecc_curve_mark_enabled(). This only works if the configuration file > + * uses the allowlisting mode. > + * > + * Returns: 0 on success or negative error code otherwise. > + * > + * Since: 3.7.3 > + */ > +int gnutls_ecc_curve_mark_disabled(gnutls_ecc_curve_t curve) That's a very good point and it also made me think that we could reduce the number of new APIs if we just add the extra argument :-) So now those public functions take the `enabled` (or `secure`) argument. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_732633275 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 Nov 14 12:37:00 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 14 Nov 2021 11:37:00 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: All discussions on merge request !1427 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 14 15:23:10 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 14 Nov 2021 14:23:10 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 Project:Branches: dueno/gnutls:wip/dueno/thr to gnutls/gnutls:master Author: Daiki Ueno Add a description of the new feature/bug fix. Reference any relevant bugs. ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1485 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 Nov 15 08:08:42 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 07:08:42 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented: @asosedkin sorry to bother you again; I came up with another threading fixes, which I'd like to rebase !1427 on before merging it. Could you take a look? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_732900813 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 Nov 15 11:52:32 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 10:52:32 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/kx.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733147890 > + > + keylogfile = secure_getenv("SSLKEYLOGFILE"); > + if (keylogfile != NULL && *keylogfile != '\0') { Mild: Why the new non-empty-string check? My vote's for warning. -- Alexander Sosedkin started a new discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733147897 > + > +static void > +tcti_once_init(void) Do I understand correctly that a library reinitialization (e.g., with `gnutls_global_set_mutex`) will deinit `tcti_ctx` and never reinit it again? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 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 Nov 15 11:54:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 10:54:06 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Mild: several if statements throughout the code might benefit from `unlikely` (e.g., I see wrappers not using it, but then wrappers' callers using it). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733149795 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 Nov 15 16:30:09 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 15:30:09 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/kx.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733505661 > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wanalyzer-file-leak" > > +GNUTLS_ONCE(keylog_once); > + > +static void > +keylog_once_init(void) > +{ > + const char *keylogfile; > + > + keylogfile = secure_getenv("SSLKEYLOGFILE"); > + if (keylogfile != NULL && *keylogfile != '\0') { I think it's a classic idiom to allow users to invalidate the effect of envvar with `SSLKEYLOGFILE= command`. It also aligns with the NSS [behavior](https://hg.mozilla.org/projects/nss/file/77b0c937dfaac74495cd2b498370b0e2668562bb/lib/ssl/sslsock.c#l3919). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733505661 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 Nov 15 16:36:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 15:36:40 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733515776 > > -int install_tpm2_key(struct tpm2_info_st *info, gnutls_privkey_t pkey, > - unsigned int parent, bool emptyauth, > - gnutls_datum_t *privdata, gnutls_datum_t *pubdata) > +GNUTLS_ONCE(tcti_once); > + > +void > +tpm2_tcti_deinit(void) > +{ > + if (tcti_ctx) { > + Tss2_TctiLdr_Finalize(&tcti_ctx); > + } > +} > + > +static void > +tcti_once_init(void) Yes; afaik library initialization (either implicit or explicit) is already implemented like a once: multiple calls to `gnutls_global_init` only takes effect for the first time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733515776 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 Nov 15 16:43:08 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 15:43:08 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/kx.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733524301 > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wanalyzer-file-leak" > > +GNUTLS_ONCE(keylog_once); > + > +static void > +keylog_once_init(void) > +{ > + const char *keylogfile; > + > + keylogfile = secure_getenv("SSLKEYLOGFILE"); > + if (keylogfile != NULL && *keylogfile != '\0') { OK if that's standard, guess unsetting is less ergonomic. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733524301 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 Nov 15 16:59:09 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 15:59:09 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733549577 > > -int install_tpm2_key(struct tpm2_info_st *info, gnutls_privkey_t pkey, > - unsigned int parent, bool emptyauth, > - gnutls_datum_t *privdata, gnutls_datum_t *pubdata) > +GNUTLS_ONCE(tcti_once); > + > +void > +tpm2_tcti_deinit(void) > +{ > + if (tcti_ctx) { > + Tss2_TctiLdr_Finalize(&tcti_ctx); > + } > +} > + > +static void > +tcti_once_init(void) I see an initialization counter `_gnutls_init` in `gnutls_global_init`, yes, and I'm concerned with what happens when it dips below 1 and gnutls deinits for real. For example, `gnutls_global_set_mutex`'s implementation seems to rely on such below-1 dipping. Even though it doesn't actually verify that the counter went below 1, which it probably should, the purpose of it seems to be to trigger an actual deinit, swap out mutex routines for user-provided ones and init back using them. Such code suggests that "full deinit to then reinit back" is a supported usage scenario, and in this case I don't like initializing resources just on the first time guarded on a non-resetting 'once'. Bringing be to doubt the commit's stated goal 'This makes sure that the global variables are initialized only once' is a good idea. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733549577 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 Nov 15 18:47:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 17:47:23 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733683249 > > -int install_tpm2_key(struct tpm2_info_st *info, gnutls_privkey_t pkey, > - unsigned int parent, bool emptyauth, > - gnutls_datum_t *privdata, gnutls_datum_t *pubdata) > +GNUTLS_ONCE(tcti_once); > + > +void > +tpm2_tcti_deinit(void) > +{ > + if (tcti_ctx) { > + Tss2_TctiLdr_Finalize(&tcti_ctx); > + } > +} > + > +static void > +tcti_once_init(void) We could conditionalize it for implicit and explicit initialization, as we [do](https://github.com/p11-glue/p11-kit/blob/master/common/library.h#L73) in p11-kit (though it also indicates that gnutls reinitialization wouldn't work if it is linked with p11-kit). Considering this and the documentation of `gnutls_global_init` ("This function can be called many times, but will only do something the first time."), I'm learning to stop supporting the reinitialization scenario. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733683249 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 Nov 15 19:21:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 15 Nov 2021 18:21:27 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733707487 > > -int install_tpm2_key(struct tpm2_info_st *info, gnutls_privkey_t pkey, > - unsigned int parent, bool emptyauth, > - gnutls_datum_t *privdata, gnutls_datum_t *pubdata) > +GNUTLS_ONCE(tcti_once); > + > +void > +tpm2_tcti_deinit(void) > +{ > + if (tcti_ctx) { > + Tss2_TctiLdr_Finalize(&tcti_ctx); > + } > +} > + > +static void > +tcti_once_init(void) If we can deprecate `gnutls_global_set_mutex` and the whole idea of reinitializing after a deinit, then I'm OK with once. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_733707487 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 Nov 16 12:31:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Nov 2021 11:31:44 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: sendifle (!1486) In-Reply-To: References: Message-ID: Reassigned merge request 1486 https://gitlab.com/gnutls/gnutls/-/merge_requests/1486 Assignee changed to Franti?ek Kren?elok -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1486 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 Nov 16 12:31:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Nov 2021 11:31:44 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: sendifle (!1486) In-Reply-To: References: Message-ID: Reviewer changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1486 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 Nov 16 12:32:21 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Nov 2021 11:32:21 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: sendifle (!1486) References: Message-ID: Franti?ek Kren?elok created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1486 Project:Branches: FrantisekKrenzelok/gnutls:ktls_sendfile to gnutls/gnutls:master Author: Franti?ek Kren?elok Assignee: Franti?ek Kren?elok Reviewer: Daiki Ueno add gnutls_record_send_file() and _gnutls_ktls_send_file() for sending files via KTLS to increase performance ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1486 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 Nov 16 17:16:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 16 Nov 2021 16:16:44 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tpm2_esys.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_734806728 > > -int install_tpm2_key(struct tpm2_info_st *info, gnutls_privkey_t pkey, > - unsigned int parent, bool emptyauth, > - gnutls_datum_t *privdata, gnutls_datum_t *pubdata) > +GNUTLS_ONCE(tcti_once); > + > +void > +tpm2_tcti_deinit(void) > +{ > + if (tcti_ctx) { > + Tss2_TctiLdr_Finalize(&tcti_ctx); > + } > +} > + > +static void > +tcti_once_init(void) Looking more closely at `gnutls_global_set_mutex`, the reinitialization logic seems to be added to support the implicit initialization of the library (i.e., in that case there is no way to call `gnutls_global_set_mutex` before "any other gnutls function"). The actual effect of this reinitialization, as far as I understand, is to re-init (dynamic) mutexes created at `gnutls_global_init`; which are: - `_gnutls_file_mutex` - `_gnutls_pkcs11_mutex` I wonder if those could be turned into a static mutex, then we wouldn't need library reinitialization. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_734806728 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 Nov 17 08:10:59 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Nov 2021 07:10:59 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_735310623 Indeed; I've moved `unlikely` to wrappers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_735310623 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 Nov 17 12:46:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Nov 2021 11:46:27 +0000 Subject: [gnutls-devel] GnuTLS | fips: plumb service indicator to public key algorithms (d66b7132) In-Reply-To: References: Message-ID: Pedro Monreal started a new discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/commit/d66b713242ed5577f978e3c86c989142a817caa4#note_735619857 > + > +void > +_gnutls_fips_set_operation_state(gnutls_fips140_operation_state_t state) > +{ > +#ifdef ENABLE_FIPS140 > + if (!_tfips_context) { > + _gnutls_debug_log("FIPS140-2 context is not set\n"); > + return; > + } > + > + switch (_tfips_context->state) { > + case GNUTLS_FIPS140_OPERATION_STATE_INITIAL: > + _tfips_context->state = state; > + _gnutls_debug_log("FIPS140-2 operation mode switched from %s to %s\n", > + operation_state_to_string(_tfips_context->state), > + operation_state_to_string(state)); The debug message would print the same string values. Consider this: ``` _gnutls_debug_log("FIPS140-2 operation mode switched from %s to %s\n", operation_state_to_string(GNUTLS_FIPS140_OPERATION_STATE_INITIAL), operation_state_to_string(state)); ``` Check also the other cases. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/d66b713242ed5577f978e3c86c989142a817caa4#note_735619857 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 Nov 17 13:52:09 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Nov 2021 12:52:09 +0000 Subject: [gnutls-devel] GnuTLS | fips: plumb service indicator to public key algorithms (d66b7132) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/commit/d66b713242ed5577f978e3c86c989142a817caa4#note_735693943 > + > +void > +_gnutls_fips_set_operation_state(gnutls_fips140_operation_state_t state) > +{ > +#ifdef ENABLE_FIPS140 > + if (!_tfips_context) { > + _gnutls_debug_log("FIPS140-2 context is not set\n"); > + return; > + } > + > + switch (_tfips_context->state) { > + case GNUTLS_FIPS140_OPERATION_STATE_INITIAL: > + _tfips_context->state = state; > + _gnutls_debug_log("FIPS140-2 operation mode switched from %s to %s\n", > + operation_state_to_string(_tfips_context->state), > + operation_state_to_string(state)); Good catch, thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/d66b713242ed5577f978e3c86c989142a817caa4#note_735693943 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 Nov 17 13:57:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 17 Nov 2021 12:57:06 +0000 Subject: [gnutls-devel] GnuTLS | Cannot export hidden symbol __gnutls_arm_cpuid_s when building on macOS Monterey in M1 machine. (#1288) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1288#note_735700061 Actually the bundled libtasn1 has been updated to the 4.17.0 release, which should contain the fix; I suspect we might need to adjust the LDFLAGS for minitasn1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1288#note_735700061 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 Nov 18 07:54:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Nov 2021 06:54:53 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: All discussions on merge request !1485 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 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 Nov 18 10:06:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Nov 2021 09:06:54 +0000 Subject: [gnutls-devel] GnuTLS | Draft: fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno commented: @smuellerDD this is the service indicator implementation we discussed some time ago. I'm currently adding the state transitions everywhere, but stumbled on where and when to trigger the indication. Someone told me it would be reasonable to add it right after validating the arguments, but I'm a bit skeptical about that. Suppose we have a FFDH calculation; when an approved parameter is chosen, we know that the library is going to perform the actual calculation, though it will also validates Z (as in bea53f1b46a64d6dcf5bbe4794740c4d4459f9bf) after that. If it fails (though unlikely), should we mark the state as if there was no crypto operation performed? The DH function nevertheless return an error in that case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_736633369 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 Nov 18 19:08:12 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Nov 2021 18:08:12 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: fix CPU feature detection for Intel CPUs (!1487) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1487 Project:Branches: dueno/gnutls:wip/dueno/cpuid to gnutls/gnutls:master Author: Daiki Ueno This fixes read_cpuid_vals to correctly read the CPUID quadruple, as well as to set the bit the ustream CRYPTOGAMS uses to identify Intel CPUs. Suggested by Rafael Gieschke in: https://gitlab.com/gnutls/gnutls/-/issues/1282 ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1487 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 Nov 18 19:12:14 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 18 Nov 2021 18:12:14 +0000 Subject: [gnutls-devel] GnuTLS | x86(_64): CPU feature detection broken (#1282) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks for the report. I think point 3 is already handled by `check_4th_gen_intel_features`, while the other issues still apply. Could you check !1487 if it's sufficient? Also I cannot reproduce `SIGILL` with `noxsave`, on Linux 5.14 & Core i7-8650U, where `/proc/cpuinfo` reports no `avx*` if `noxsave` is set. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1282#note_737372526 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 Nov 19 20:23:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 19 Nov 2021 19:23:27 +0000 Subject: [gnutls-devel] GnuTLS | Draft: fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_738647227 OK, we have `GNUTLS_FIPS140_OPERATION_STATE_ERROR` for that purpose. So, I'm going to add those calls like: ```c void some_crypto_op(...) { int ret; bool approved = true; switch (...) { case APPROVED_ALGO1: break; case APPROVED_ALGO2: if (!approved_mode) approved = false; break; case NON_APPROVED_ALGO: approved = false; break; } ... cleanup: if (ret < 0) { /* state transition to GNUTLS_FIPS140_OPERATION_STATE_ERROR */ } else if (approved) { /* state transition to GNUTLS_FIPS140_OPERATION_STATE_APPROVED */ } else { /* state transition to GNUTLS_FIPS140_OPERATION_STATE_NOT_APPROVED */ } } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_738647227 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 Nov 20 12:56:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 20 Nov 2021 11:56:24 +0000 Subject: [gnutls-devel] GnuTLS | Draft: fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_738886152 That sounds like an appropriate handling in your example Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_738886152 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 Nov 22 11:17:57 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 22 Nov 2021 10:17:57 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Merge request !1485 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 Project:Branches: dueno/gnutls:wip/dueno/thr to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 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 Nov 22 11:59:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 22 Nov 2021 10:59:40 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Merge request !1485 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 Project:Branches: dueno/gnutls:wip/dueno/thr to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485 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 Nov 22 11:59:49 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 22 Nov 2021 10:59:49 +0000 Subject: [gnutls-devel] GnuTLS | locks: couple of improvements using Gnulib glthread (!1485) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1485#note_739930714 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 Nov 23 15:30:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 23 Nov 2021 14:30:24 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno changed the draft status of merge request !1465 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465 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 Nov 23 15:31:59 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 23 Nov 2021 14:31:59 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_741464544 Thank you; I've updated with this pattern (for public key operations; symmetric key operations need a different approach, because they usually span multiple function calls: init, encrypt/decrypt, deinit, etc). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_741464544 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 Nov 23 15:32:01 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 23 Nov 2021 14:32:01 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: All discussions on merge request !1465 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1465 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465 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 Nov 23 15:38:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 23 Nov 2021 14:38:46 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno commented: @smuellerDD I think this is almost ready; could you take a look? I've also adjusted some function/enum names in the linked gdoc. A main caveat is that GnuTLS already prohibits most of the invalid uses of crypto primitives (such as RSA key shorter than 2048 bits) in FIPS mode and returns an error; this is the case of "Group 4" in the [IG](https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf). Therefore checks for "approved"/"non-approved" checks are only found in particular operations (e.g., uses of Edwards curves; I know they are being approved, but currently only prohibited by other means: crypto-policies). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_741473996 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 Nov 24 08:09:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 24 Nov 2021 07:09:37 +0000 Subject: [gnutls-devel] GnuTLS | Build errors with MinGW (#1283) In-Reply-To: References: Message-ID: Daiki Ueno commented: After a chat on Matrix, it turned out to be: - This is a build with `--disable-shared --enable-static` - Looks similar to https://gitlab.com/gnutls/gnutls/-/issues/1117 - It for some reason works now I'm closing this for now; feel free to reopen if the issue happens again, or continue the discussion on #1117. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1283#note_742145141 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 Nov 24 08:09:38 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 24 Nov 2021 07:09:38 +0000 Subject: [gnutls-devel] GnuTLS | Build errors with MinGW (#1283) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1283: https://gitlab.com/gnutls/gnutls/-/issues/1283 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1283 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 Nov 24 10:15:34 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 24 Nov 2021 09:15:34 +0000 Subject: [gnutls-devel] libtasn1 | License of libtasn1.map (#38) References: Message-ID: Dylan A?ssi created an issue: https://gitlab.com/gnutls/libtasn1/-/issues/38 Hello, Currently, `libtasn1.map` is used to build the library , but this file is under GPL-3+. Even if it can be considered part of the buildsystem, map files can also be considered in the grey area. Would it be possible to relicensing this file under LGPL-2.1+ like the library to make it clear there is no license issue with it? Thanks for considering. Best, Dylan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/38 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 Nov 24 18:46:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 24 Nov 2021 17:46:58 +0000 Subject: [gnutls-devel] GnuTLS | build: update to use the latest valgrind-tests module from Gnulib (!1488) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488 Project:Branches: dueno/gnutls:wip/dueno/valgrind-tests to gnutls/gnutls:master Author: Daiki Ueno Fixes: #1253 ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1488 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 Nov 25 11:59:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 10:59:54 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Gisle Vanem started a new discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743634651 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; This does not work with MSVC. Error: ```c system/sockets.c(87): error C2057: expected constant expression system/sockets.c(87): error C2466: cannot allocate an array of constant size 0 system/sockets.c(87): error C2133: 'bufs': unknown size ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743634651 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 Nov 25 13:09:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:09:54 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743720903 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; That's correct, MSVC does not support variable length array. I was not aware that GnuTLS supports compiling by MSVC. I'll make a patch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743720903 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 Nov 25 13:15:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:15:27 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Gisle Vanem commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743727396 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; I replaced with: `WSABUF *bufs = alloca (sizeof(WSABUF) * iovec_cnt);` to fix it here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743727396 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 Nov 25 13:24:32 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:24:32 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743737231 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; Maybe a better solution would be small fixed size + malloced version for large size? This way we can avoid stack overflow in special cases. `alloc()` on Windows has some limitations: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca?view=msvc-170 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743737231 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 Nov 25 13:36:47 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:36:47 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Gisle Vanem commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743752305 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; Surely there must be a upper-limit on `iovec_cnt`?
E.g. `#define IOVEC_MAX_CNT 20` or something. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743752305 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 Nov 25 13:44:41 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:44:41 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743760512 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; There is no limit on WinNT-based Windows versions. It was limited to 16 buffers for Windows 9x/ME, but it was a very long time ago. :smile: By the way, POSIX version does not check for the limits, while Solaris (for example) still limited to 16 buffers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743760512 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 Nov 25 13:54:18 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:54:18 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building with compilers without VLA support (!1489) References: Message-ID: Evgeny Grin created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489 Project:Branches: karlson2k/gnutls:fix_non_vla_01 to gnutls/gnutls:master Author: Evgeny Grin Compilation with MSVC is broken as MSVC does not support variable length arrays. Reported here: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743634651 ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1489 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 Nov 25 13:55:50 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 12:55:50 +0000 Subject: [gnutls-devel] GnuTLS | Sockets: implement sendmsg()-like functions on Win32 (bfd453f3) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743773992 > { > return send(GNUTLS_POINTER_TO_INT(ptr), data, data_size, 0); > } > + > +ssize_t > +system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > + int iovec_cnt) > +{ > + WSABUF bufs[iovec_cnt]; The fix: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743773992 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 Nov 25 14:34:35 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 13:34:35 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno commented: @asosedkin could you give it a formal review? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_743828873 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 Nov 25 19:59:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 25 Nov 2021 18:59:19 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259749 > > The valid values for the options above can be found in the 'Protocols', 'Digests' > 'PK-signatures', 'Protocols', 'Ciphrers', and 'MACs' fields of the output of @code{gnutls-cli --list}. unrelated typo (`Ciphrers`) -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259750 > +insecure or disabled, and shall be explicitly turned on by the options > +in the @code{[overrides]} section. Those options are mutually > +exclusive to the above ones for the blocklisting mode (the default) That still sounds like one can mix, e.g., `secure`/`insecure` options as long as they refer to different classes of algorithms. Maybe better state the modes are mutually exclusive, not options. -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259751 > @end example > > +The following example demonstrates the use of the allowlisting Would it be beneficial to provide a longer example that allows TLS with at least one ciphersuite? -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259752 > +allowlist} in the @code{[global]} section. > + > +When the allowlisting mode is in effect, it is also possible for the applications to modify the setting through the API. Should we spell out that this is in addition to priority string appending + has to happen beforehand? -- Alexander Sosedkin started a new discussion on lib/algorithms/ecc.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259753 > + * enabled or disabled. This only has effect when the curve is > + * enabled through the allowlisting mode in the configuration file, or > + * the setting is modified with a prior call to this function. Really minor: I'd write "or when" here and not just "or" to prevent reading "A when B or C" as "(A when B), otherwise C" instead of "A when (either B or C)". -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259755 > +allowlist} in the @code{[global]} section. > + > +When the allowlisting mode is in effect, it is also possible for the applications to modify the setting through the API. Should we put restrictions on the priority string used with allowlisting? -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259756 > +} > + > +/* This function parse the global section of the configuration file. s/parse/parses/ -- Alexander Sosedkin started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_744259758 > - ss, ss_len); > + if (system_wide_config.allowlisting && > + ss_len == sizeof(LEVEL_SYSTEM) - 1 && Possible off-by-one? -- Alexander Sosedkin commented: It's hard to do that, because it's big, because I've spent too much time with it to be a proper critic of it and because I'm the requester =) Nevertheless, I've tried to make one more pass (not too productive) and summarize my thoughts about it: * small things, mostly in comments: inline * API: r+, * (most "eh" thing is that the sign 3-level situation got one notch more confusing with the enable/disable->set transition, but I'm not a fan of exposing a 3-level enum for it either, so, OK?) * Compatibility: r+, it's not going to break existing users unless new format is opted into * Docs: I have reservations * I'd still insist on a warning that the mode and the API are new and, IDK, in preview until the next minor release? * Partly because it would be awesome to have someone actually use it in an app and report the findings... * ... partly because we have some known issues, and I feel we should be upfront about that. * Should we restrict what can be used as SYSTEM value? * new API / priority string interaction must be clarified further * calls must happen before setting custom priority strings * subsequent priority string appending overrides both config values and API calls modifications * Known issues I recall having: * Sigalgs need to be ordered carefully to avoid duplicates (rhbz1983646) * Something was iffy with enabling sigalgs with priority strings (rhbz1998084) * [Protocol enabling through API was found to not always work as expected](https://gitlab.com/asosedkin/gnutls/-/commit/55665fd6e25a540e61ef39ee31254e10f22e8814) * plus possibly more similarly contained issues of comparable impact, because * Test coverage still needs more work My main thesis is, issues "contained" behind a switch are not a blocker for mainlining, but the switch better be temporarily decorated with a warning. Whoever's brave enough to use it first deserves to know what they're heading into. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 26 09:57:15 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 08:57:15 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building with compilers without VLA support (!1489) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489#note_744605766 > system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > int iovec_cnt) > { > - WSABUF bufs[iovec_cnt]; > + WSABUF bufs_stack[16]; > + WSABUF * bufs; > DWORD bytes_sent; > int to_send_cnt = 0; > size_t to_send_bytes = 0; > + ssize_t ret; > + > + if ((size_t)iovec_cnt > sizeof(bufs_stack) / sizeof(bufs_stack[0])) > + { > + bufs = (WSABUF *) malloc (iovec_cnt * sizeof(WSABUF)); I wonder what if we just force the 16 elements maximum instead of allocating extra; in that case `system_writev` would still report the actual bytes written so the caller can repeat sending? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489#note_744605766 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 Nov 26 12:12:51 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 11:12:51 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) References: Message-ID: Evgeny Grin created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 Project:Branches: karlson2k/gnutls:fix_non_vla_02 to gnutls/gnutls:master Author: Evgeny Grin Compilation with MSVC is broken as MSVC does not support variable length arrays. The second commit fixed warning on Windows 32-bit. Reported here: https://gitlab.com/gnutls/gnutls/-/commit/bfd453f39cb6126e561000a711264b2535eefc36#note_743634651 This MR is an alternative version of https://gitlab.com/gnutls/gnutls/-/merge_requests/1489 ## 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) * [x] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1490 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 Nov 26 12:13:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 11:13:37 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building with compilers without VLA support (!1489) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489#note_744784412 > system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > int iovec_cnt) > { > - WSABUF bufs[iovec_cnt]; > + WSABUF bufs_stack[16]; > + WSABUF * bufs; > DWORD bytes_sent; > int to_send_cnt = 0; > size_t to_send_bytes = 0; > + ssize_t ret; > + > + if ((size_t)iovec_cnt > sizeof(bufs_stack) / sizeof(bufs_stack[0])) > + { > + bufs = (WSABUF *) malloc (iovec_cnt * sizeof(WSABUF)); Alternative version: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489#note_744784412 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 Nov 26 15:36:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 14:36:25 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745060082 > system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > int iovec_cnt) > { > - WSABUF bufs[iovec_cnt]; > + WSABUF bufs[32]; > DWORD bytes_sent; > int to_send_cnt = 0; > size_t to_send_bytes = 0; > > - while (to_send_cnt < iovec_cnt && to_send_bytes < SSIZE_MAX) { > + while (to_send_cnt < iovec_cnt && > + (size_t) to_send_cnt < sizeof(bufs) / sizeof(bufs[0]) && nit: ```suggestion:-1+0 while (to_send_cnt < MIN((size_t) iovec_cnt, sizeof(bufs) / sizeof(bufs[0])) && ``` after defining `to_send_cnt` as `size_t`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745060082 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 Nov 26 15:36:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 14:36:40 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Merge request !1490 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 Project:Branches: karlson2k/gnutls:fix_non_vla_02 to gnutls/gnutls:master Author: Evgeny Grin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 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 Nov 26 17:03:50 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 16:03:50 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745152847 > system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > int iovec_cnt) > { > - WSABUF bufs[iovec_cnt]; > + WSABUF bufs[32]; > DWORD bytes_sent; > int to_send_cnt = 0; > size_t to_send_bytes = 0; > > - while (to_send_cnt < iovec_cnt && to_send_bytes < SSIZE_MAX) { > + while (to_send_cnt < iovec_cnt && > + (size_t) to_send_cnt < sizeof(bufs) / sizeof(bufs[0]) && MR has been updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745152847 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 Nov 26 17:03:52 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 16:03:52 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: All discussions on merge request !1490 were resolved by Evgeny Grin https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 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 Nov 26 17:03:16 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 16:03:16 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Evgeny Grin commented on a discussion on lib/system/sockets.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745152351 > system_writev(gnutls_transport_ptr_t ptr, const giovec_t * iovec, > int iovec_cnt) > { > - WSABUF bufs[iovec_cnt]; > + WSABUF bufs[32]; > DWORD bytes_sent; > int to_send_cnt = 0; > size_t to_send_bytes = 0; > > - while (to_send_cnt < iovec_cnt && to_send_bytes < SSIZE_MAX) { > + while (to_send_cnt < iovec_cnt && > + (size_t) to_send_cnt < sizeof(bufs) / sizeof(bufs[0]) && Good point, readability is bad. I think that I've even better way to improve readability (and code performance). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745152351 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 Nov 26 17:49:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 16:49:53 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Merge request !1490 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 Project:Branches: karlson2k/gnutls:fix_non_vla_02 to gnutls/gnutls:master Author: Evgeny Grin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 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 Nov 26 17:50:01 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 16:50:01 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490#note_745197497 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 Nov 26 18:11:48 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 17:11:48 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building for Windows with compilers without VLA support (alternative version) (!1490) In-Reply-To: References: Message-ID: Merge request !1490 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 Project:Branches: karlson2k/gnutls:fix_non_vla_02 to gnutls/gnutls:master Author: Evgeny Grin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1490 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 Nov 26 18:16:10 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 17:16:10 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745218573 > gnutls_strerror(ret)); > break; > } > - > - p = _name_val_array_value(system_wide_config.priority_strings, > - ss, ss_len); > + if (system_wide_config.allowlisting && > + ss_len == sizeof(LEVEL_SYSTEM) - 1 && I think this is to exclude NUL byte at the end of `LEVEL_SYSTEM`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745218573 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 Nov 26 18:43:55 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 17:43:55 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745245648 > gnutls_strerror(ret)); > break; > } > - > - p = _name_val_array_value(system_wide_config.priority_strings, > - ss, ss_len); > + if (system_wide_config.allowlisting && > + ss_len == sizeof(LEVEL_SYSTEM) - 1 && Yeah, I've overlooked that we're comparing inline and calculated the length beforehand, so we don't want it included in the comparison. Sorry for the noise. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745245648 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 Nov 26 18:43:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 17:43:54 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: All discussions on merge request !1427 were resolved by Alexander Sosedkin https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 26 19:07:40 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 18:07:40 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745273038 > +listed below in the @code{[overrides]} section. As the allowlisting > +mode is mutually exclusive to the blocklisting mode, the options > +listed above for the blocklisting mode is forbidden in the s/is/are/ -- Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745273040 > +configuration file is generated by support tool distributed by the > +operating systems, such as > + at uref{https://gitlab.com/redhat-crypto/fedora-crypto-policies/,crypto-policies}. Oh, if only our tools possessed innate understanding of algorithm interdependencies =) Alternative phrasing suggestion: "Allowlisting configuration mode is intended to be used by the operating system vendors that prefer laying out the library defaults exhaustively instead on depending on gnutls presets, such as NORMAL. Applications are then expected to optionally disable or enable only select a subset algorithms on top of the vendor-provided configuration." Clearer motivation for the vendors, less sounding like library users need to start looking for config-generation tools. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 26 19:59:30 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 18:59:30 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building with compilers without VLA support (!1489) In-Reply-To: References: Message-ID: Merge request !1489 was closed by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489 Project:Branches: karlson2k/gnutls:fix_non_vla_01 to gnutls/gnutls:master Author: Evgeny Grin Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489 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 Nov 26 19:59:30 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 26 Nov 2021 18:59:30 +0000 Subject: [gnutls-devel] GnuTLS | sockets: fixed building with compilers without VLA support (!1489) In-Reply-To: References: Message-ID: Daiki Ueno commented: Superseded by !1490. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1489#note_745298343 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 Nov 27 08:00:22 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 07:00:22 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745412379 > to be disabled or enabled. > > The valid values for the options above can be found in the 'Protocols', 'Digests' > -'PK-signatures', 'Protocols', 'Ciphrers', and 'MACs' fields of the output of @code{gnutls-cli --list}. > +'PK-signatures', 'Protocols', 'Ciphers', and 'MACs' fields of the output of @code{gnutls-cli --list}. > > Sometimes the system administrator wants to enable only specific > algorithms, despite the library defaults. GnuTLS provides an > alternative mode of overriding: allowlisting. > > +As shown below in the examples, it is hard to use this mode correctly, > +as it requires understanding of how algorithms are used underneath by > +the protocols. Therefore, it is highly recommended that the > +configuration file is generated by support tool distributed by the > +operating systems, such as > + at uref{https://gitlab.com/redhat-crypto/fedora-crypto-policies/,crypto-policies}. Thanks for the suggestion; incorporated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745412379 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 Nov 27 08:00:22 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 07:00:22 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: All discussions on merge request !1427 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 27 14:47:52 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 13:47:52 +0000 Subject: [gnutls-devel] GnuTLS | build: update to use the latest valgrind-tests module from Gnulib (!1488) In-Reply-To: References: Message-ID: Merge request !1488 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488 Project:Branches: dueno/gnutls:wip/dueno/valgrind-tests to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488 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 Nov 27 14:48:28 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 13:48:28 +0000 Subject: [gnutls-devel] GnuTLS | build: update to use the latest valgrind-tests module from Gnulib (!1488) In-Reply-To: References: Message-ID: Daiki Ueno commented: Merging this without approval, as it only affects the build infrastructure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488#note_745473914 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 Nov 27 15:10:32 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 14:10:32 +0000 Subject: [gnutls-devel] GnuTLS | API function to get ciphersuite name (#1291) References: Message-ID: Michael Catanzaro created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1291 ## Description of the feature: It would be nice if GnuTLS had an easy way to get the name of the current ciphersuite in use by a gnutls_session_t ([suggested by Daiki](https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/194#note_1321126)). ## Applications that this feature may be relevant to: glib-networking would use this. ## Is this feature implemented in other libraries (and which) The current glib-networking implementation does: ``` static gchar * get_ciphersuite_name (gnutls_session_t session) { gnutls_protocol_t protocol_version = gnutls_protocol_get_version (session); char *cipher_name; char *result; if (protocol_version <= GNUTLS_TLS1_2 || (protocol_version >= GNUTLS_DTLS0_9 && protocol_version <= GNUTLS_DTLS1_2)) { return g_strdup (gnutls_cipher_suite_get_name (gnutls_kx_get (session), gnutls_cipher_get (session), gnutls_mac_get (session))); } cipher_name = g_strdup (gnutls_cipher_get_name (gnutls_cipher_get (session))); for (char *c = cipher_name; *c != '\0'; c++) { if (*c == '-') *c = '_'; } result = g_strdup_printf ("TLS_%s_%s", cipher_name, gnutls_digest_get_name (gnutls_prf_hash_get (session))); g_free (cipher_name); return result; } ``` Ideally we would replace all that with one call to GnuTLS. Additionally, for TLS 1.2, that returns the "GnuTLS" name of the ciphersuite, which is different from the standard IANA names. The new API should probably always return the standard, IANA-style ciphersuite names. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1291 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 Nov 27 16:50:49 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 15:50:49 +0000 Subject: [gnutls-devel] GnuTLS | build: stop running abi-dump-latest at "make files-update" (!1491) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1491 Project:Branches: dueno/gnutls:wip/dueno/abi-check-latest to gnutls/gnutls:master Author: Daiki Ueno This is a follow-up after !1481. ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1491 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 Nov 27 17:57:43 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 16:57:43 +0000 Subject: [gnutls-devel] GnuTLS | build: update to use the latest valgrind-tests module from Gnulib (!1488) In-Reply-To: References: Message-ID: Merge request !1488 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488 Project:Branches: dueno/gnutls:wip/dueno/valgrind-tests to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1488 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 Nov 27 17:57:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 16:57:44 +0000 Subject: [gnutls-devel] GnuTLS | --enable-valgrind-tests broke in 3.7.2, can't open suppressions file, leads to valgrind not invoked (#1253) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno via merge request !1488 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1488) Issue #1253: https://gitlab.com/gnutls/gnutls/-/issues/1253 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1253 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 Nov 27 18:07:48 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 17:07:48 +0000 Subject: [gnutls-devel] GnuTLS | build: stop running abi-dump-latest at "make files-update" (!1491) In-Reply-To: References: Message-ID: Daiki Ueno commented: @juaristi would you mind giving a quick review on this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1491#note_745510736 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 Nov 27 18:19:57 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 27 Nov 2021 17:19:57 +0000 Subject: [gnutls-devel] GnuTLS | ktls: API (!1477) In-Reply-To: References: Message-ID: Daiki Ueno commented: Please adjust the suppressions according to [this](https://gitlab.com/gnutls/gnutls/-/blob/ecad51a3993e20a22ab62c9b716d76b0def93de5/CONTRIBUTING.md#introducing-new-functions-api). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_745515203 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 Nov 28 10:54:48 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 09:54:48 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/fips.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745612424 > } > > - return 0; > + return false; > +} > + > +inline static bool > +is_cipher_algo_forbidden_in_fips(gnutls_cipher_algorithm_t algo) > +{ > + switch (algo) { > + case GNUTLS_CIPHER_AES_128_CBC: > + case GNUTLS_CIPHER_AES_256_CBC: > + case GNUTLS_CIPHER_AES_192_CBC: > + case GNUTLS_CIPHER_AES_128_GCM: > + case GNUTLS_CIPHER_AES_192_GCM: > + case GNUTLS_CIPHER_AES_256_GCM: For the records: I would like to mention that GCM is a bit special. GCM is only approved to be used as part of the TLS protocol stack. The general-purpose use of GCM is not approved. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745612424 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 Nov 28 11:07:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:07:24 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745614209 > > break; > } > case GNUTLS_PK_EC: Shouldn't there be a test of something like: switch (curve) { P224: P256 P384: P521: break; default: not_approved = true; } -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745614209 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 Nov 28 11:08:41 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:08:41 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745614359 > unsigned int flags) > { > int ret; > + bool not_approved = false; > > switch (algo) { > case GNUTLS_PK_DH: { Shouldn't there be a check like if (length(x) < 2048) not_approved = true; -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745614359 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 Nov 28 11:14:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:14:44 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615130 > break; > } > #endif > case GNUTLS_PK_ECDSA: /* we do ECDSA */ See above: shouldn't there be a limit for the approved curves? Note, for legacy, P-192 as well as SHA-1 is allowed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615130 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 Nov 28 11:17:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:17:06 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615409 > break; > } > #endif > case GNUTLS_PK_ECDSA: /* ECDSA */ See above: shouldn't there be a check for the approved curves? Note, for sigver, P-192 is approved for legacy mode. Also SHA-1 is approved for legacy mode. Otherwise only SHA-2 is approved. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615409 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 Nov 28 11:19:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:19:46 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615743 > ecc_point_clear(&pub); > break; > } > case GNUTLS_PK_DSA: Would it make sense to disregard DSA entirely? I.e. mark it not_approved = true? Note, DSA is currently being defined as sunset with the current draft of FIPS 186-5. As this is still a draft, we cannot rely on it nor can we know for certain that DSA will be sunset. In any case, if DSA is intended to be left approved, shouldn't there be a check: (a) that the key is >= 2048 and (b) the hash is SHA-2 (and SHA-1 for legacy purpose)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615743 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 Nov 28 11:20:36 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:20:36 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615828 > > break; > } > case GNUTLS_PK_RSA: Shouldn't there be a check that the key size is >= 2048 and the used hash is SHA-2 (SHA-1 for legacy sigver is approved, too). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615828 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 Nov 28 11:21:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:21:06 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615879 > > break; > } > case GNUTLS_PK_RSA_PSS: See RSA above -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745615879 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 Nov 28 11:31:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:31:19 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745616984 > } > > switch (algo) { > case GNUTLS_PK_DSA: See comment about DSA above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745616984 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 Nov 28 11:32:02 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:32:02 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617065 > mpz_clear(y); > > if (ret < 0) > - goto fail; > + goto cleanup; > > break; > } > #endif > FALLTHROUGH; > case GNUTLS_PK_DH: See comment on DH key size and not_approved = true above -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617065 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 Nov 28 11:33:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:33:54 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617271 > mpz_clear(ypowq); > > if (ret < 0) > - goto fail; > + goto cleanup; > > break; > } > case GNUTLS_PK_RSA_PSS: > case GNUTLS_PK_RSA: See comment on RSA key size above: if (length(n) < 2048) not_approved = true; ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617271 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 Nov 28 11:35:34 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:35:34 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617497 > params->raw_pub.data, > params->raw_priv.data); > if (ret < 0) > - goto fail; > + goto cleanup; > > break; > } > case GNUTLS_PK_ECDSA: See comment on ECC above: shouldn't there be a check that only approved curves are used? All other curves should be treated with not_approved = true; -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745617497 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 Nov 28 11:40:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:40:53 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618065 > break; > } > #endif > case GNUTLS_PK_ECDSA: /* we do ECDSA */ Apologies - this is siggen: only P224, P256, P384 and P521 with SHA-2 should be allowed as approved algos. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618065 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 Nov 28 11:42:33 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:42:33 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618236 > } > break; > } > case GNUTLS_PK_DSA: See comment on DSA above: If you would like to keep it as approved, shouldn't there be a check setting not_approved = true if the key size < 2048 or when using any hash other than SHA2? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618236 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 Nov 28 11:43:22 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:43:22 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618325 > } > break; > } > case GNUTLS_PK_RSA: Shouldn't there be a check setting not_approved = true if n < 2048 and/or the used hash is not SHA-2? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745618325 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 Nov 28 11:54:42 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:54:42 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745619911 > * Since: 3.6.13 > */ > int > gnutls_hkdf_extract(gnutls_mac_algorithm_t mac, Please note that HKDF is a non-approved cipher. Shouldn't the thread-local state be set to non-approved? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745619911 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 Nov 28 11:56:26 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 28 Nov 2021 10:56:26 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller started a new discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745620128 > * Since: 3.6.13 > */ > int > gnutls_hkdf_expand(gnutls_mac_algorithm_t mac, See comment above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745620128 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 Nov 29 08:16:15 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 07:16:15 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745932151 > * Since: 3.6.13 > */ > int > gnutls_hkdf_extract(gnutls_mac_algorithm_t mac, If I remember correctly, it is approved as a TLS-PRF (for TLS 1.3); should we mark it as non-approved when it is used outside of the TLS context, or all uses? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745932151 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 Nov 29 09:05:02 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 08:05:02 +0000 Subject: [gnutls-devel] GnuTLS | fips: add functions to inspect thread-local FIPS operation state (!1465) In-Reply-To: References: Message-ID: Stephan Mueller commented on a discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745974142 > * Since: 3.6.13 > */ > int > gnutls_hkdf_extract(gnutls_mac_algorithm_t mac, Hi Daiki, > Daiki Ueno commented on a discussion on lib/crypto-api.c: > https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745932151 > > * Since: 3.6.13 > > */ > > > > int > > gnutls_hkdf_extract(gnutls_mac_algorithm_t mac, > > If I remember correctly, it is approved as a TLS-PRF (for TLS 1.3); should > we mark it as non-approved when it is used outside of the TLS context, or > all uses? It is approved when used as part of TLS 1.3, correct. But for a general- purpose use case it is a non-approved algorithm. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1465#note_745974142 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 Nov 29 12:13:01 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 11:13:01 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Merge request !1427 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 Project:Branches: dueno/gnutls:wip/dueno/config-allowlisting to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 29 12:14:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 11:14:24 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_746204123 > The allowlisting mode can be enabled by adding @code{override-mode = > allowlist} in the @code{[global]} section. > > -When the allowlisting mode is in effect, it is also possible for the applications to modify the setting through the API. > +The following functions allow the applications to modify the setting. > > @showfuncE{gnutls_ecc_curve_set_enabled,gnutls_sign_set_secure,gnutls_sign_set_secure_for_certs,gnutls_digest_set_secure,gnutls_protocol_set_enabled} > > +When the allowlisting mode is in effect, a @code{@@SYSTEM} priority > +string is automatically constructed from the options in the > + at code{[overrides]} section. For this reason, the above functions > +should be called before the @cde{@@SYSTEM} priority is used. CI found a typo: ``` MAKEINFO gnutls.info ./cha-config.texi:133: unknown command `cde' ./cha-config.texi:133: misplaced { ./cha-config.texi:133: misplaced } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_746204123 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 Nov 29 13:32:12 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 12:32:12 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: All discussions on merge request !1427 were resolved by Alexander Sosedkin https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 29 14:02:02 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 13:02:02 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you for the review; merging. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_746327389 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 Nov 29 14:02:09 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 13:02:09 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Merge request !1427 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 Project:Branches: dueno/gnutls:wip/dueno/config-allowlisting to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 29 14:22:03 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 13:22:03 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: fix nettle installation path (!1492) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1492 Project:Branches: dueno/gnutls:wip/dueno/nettle-master to gnutls/gnutls:master Author: Daiki Ueno This fixes the CI to actually build against locally built nettle. ## 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) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## 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/1492 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 Nov 29 14:22:50 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 13:22:50 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: fix nettle installation path (!1492) In-Reply-To: References: Message-ID: Daiki Ueno commented: I'm not starting CI for now, as it will timeout due to https://github.com/tlsfuzzer/tlsfuzzer/issues/781 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1492#note_746353423 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 Nov 29 15:20:50 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 14:20:50 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Merge request !1427 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 Project:Branches: dueno/gnutls:wip/dueno/config-allowlisting to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 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 Nov 29 16:40:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 29 Nov 2021 15:40:24 +0000 Subject: [gnutls-devel] GnuTLS | accelerated: fix CPU feature detection for Intel CPUs (!1487) In-Reply-To: References: Message-ID: Daiki Ueno commented: @FrantisekKrenzelok would you like to review this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1487#note_746544244 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 Nov 30 14:09:24 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 30 Nov 2021 13:09:24 +0000 Subject: [gnutls-devel] GnuTLS | tls: make GNUTLS_NO_TICKETS no-op in TLS 1.3 (!1475) In-Reply-To: References: Message-ID: Reviewer changed to Hubert Kario (@mention me if you need reply) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1475 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 Nov 30 14:56:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 30 Nov 2021 13:56:45 +0000 Subject: [gnutls-devel] GnuTLS | ktls: API (!1477) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1477 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/includes/gnutls/socket.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834605 > unsigned int flags); > > +int gnutls_transport_is_ktls_enabled(gnutls_session_t session); `unsigned` might be better? -- Daiki Ueno started a new discussion on lib/system/ktls.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834608 > + KTLS_RECV = 1, > + KTLS_SEND, > + KTLS_DUPLEX, If these are used as flags, I'd define them more explicitly as: ```suggestion:-2+0 KTLS_RECV = 1 << 0, KTLS_SEND = 1 << 1, KTLS_DUPLEX = KTLS_RECV | KTLS_SEND, ``` -- Daiki Ueno started a new discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834613 > + if (setsockopt (sockin, SOL_TLS, TLS_RX, > + &crypto_info, sizeof (crypto_info))) { > + session->internals.ktls_enabled ^= KTLS_RECV; The intent of this XOR is to reset the `KTLS_RECV` flag, right? If `ktls_enabled` is `KTLS_SEND` (i.e., setsockopt(TLS_ULP) has failed for TLS_RX), this will actually set `KTLS_RECV`. I'd suggest using the `lhs &= ~rhs` idiom to reset a bit flag. -- Daiki Ueno started a new discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834615 > + * Returns: 1 for enabled, 0 otherwise > * > * Since: 3.7.2 Bump to 3.7.3. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477 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 Nov 30 15:28:11 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 30 Nov 2021 14:28:11 +0000 Subject: [gnutls-devel] GnuTLS | build: stop running abi-dump-latest at "make files-update" (!1491) In-Reply-To: References: Message-ID: Reviewer changed to Franti?ek Kren?elok -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1491 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: