From gnutls-devel at lists.gnutls.org Sat Oct 1 11:44:09 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 09:44:09 +0000 Subject: [gnutls-devel] GnuTLS | NSS interoperability test - 2way TLSv1.3 (!1649) In-Reply-To: References: Message-ID: Merge request !1649 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1649 Project:Branches: ep69/gnutls:interop-nss to gnutls/gnutls:master Author: Stanislav ?idek Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1649 You're receiving 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 Oct 1 11:44:23 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 09:44:23 +0000 Subject: [gnutls-devel] GnuTLS | NSS interoperability test - 2way TLSv1.3 (!1649) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me, thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1649#note_1121290227 You're receiving 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 Oct 1 11:44:27 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 09:44:27 +0000 Subject: [gnutls-devel] GnuTLS | NSS interoperability test - 2way TLSv1.3 (!1649) In-Reply-To: References: Message-ID: Merge request !1649 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1649 Project:Branches: ep69/gnutls:interop-nss to gnutls/gnutls:master Author: Stanislav ?idek -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1649 You're receiving 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 Oct 1 13:34:23 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 11:34:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball has almost empty AUTHORS file (#1409) References: Message-ID: Andreas Metzler created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1409 Something in the release process for 3.7.8 has not worked out, AUTHORS has been emptied (only translator list remaining). ~~~ ametzler at argenau:/tmp/GNUTLS$ diff -NurBbp gnutls-3.7.7/AUTHORS gnutls-3.7.8/AUTHORS | diffstat AUTHORS | 204 ---------------------------------------------------------------- 1 file changed, 204 deletions(-) ~~~ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1409 You're receiving 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 Oct 1 19:01:36 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 17:01:36 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball signed with different key than announced (#1410) References: Message-ID: brandon kane created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1410 ## Description of problem: When attempting to verify the tarball signature, key A6AB53A01D237A94F9EEC4D0412748A40AFCC2FB is found with not match to the gnutls keyring. This also differs from the email announcement, stating key E987AB7F7E89667776D05B3BB0E9DD20B29F1432 was used. Other two keys used match the keyring ## Version of gnutls used: 3.7.8 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Gnutls direct download ## How reproducible: download 3.7.8 tarball and sig. Open Kleopatra and verify tarball. ## Actual results: Signatures found are: 5D46CB0F763405A7053556F47A75A648B3F9220C 462225C3B46F34879FC8496CD605848ED7E69871 A6AB53A01D237A94F9EEC4D0412748A40AFCC2FB Last one is not present in gnutls keyring located at https://www.gnutls.org/gnutls-release-keyring.gpg ## Expected results: Signatures found should be(according to 9/27 announcement): 5D46CB0F763405A7053556F47A75A648B3F9220C 462225C3B46F34879FC8496CD605848ED7E69871 E987AB7F7E89667776D05B3BB0E9DD20B29F1432 These three are all present in the keyring -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1410 You're receiving 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 Oct 1 19:17:13 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 17:17:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball signed with different key than announced (#1410) In-Reply-To: References: Message-ID: Issue was closed by brandon kane Issue #1410: https://gitlab.com/gnutls/gnutls/-/issues/1410 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1410 You're receiving 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 Oct 1 19:17:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Oct 2022 17:17:43 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball signed with different key than announced (#1410) In-Reply-To: References: Message-ID: brandon kane commented: Apologies, keyring was out of date(from 3.7.7 release). Updated keyring validated OK. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1410#note_1121371367 You're receiving 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 Oct 2 04:39:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 02 Oct 2022 02:39:16 +0000 Subject: [gnutls-devel] GnuTLS | boringssl early data is rejected by gnutls server because of the client ticket age > the server ticket age (#1403) In-Reply-To: References: Message-ID: Tatsuhiro Tsujikawa commented: > expected_arrival_time = adjusted_creation_time + clients_ticket_age and > adjusted_creation_time = creation_time + estimated_RTT > > clients_ticket_age = obfuscated_ticket_age - ticket_age_add I do not see server_ticket_age >= client_ticket_age to calculate expected_arrival_time. Why is that condition necessary? Client Hello Recording records Client Hello received in the system configured window and its edges are not necessarily be dependent on the server_ticket_age of particular ticket. It seems to me that GnuTLS uses that window to check ticket freshness but I think they are different things. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1403#note_1121527763 You're receiving 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 Oct 2 23:37:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 02 Oct 2022 21:37:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_ext_raw_parse returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE (#1411) References: Message-ID: Jasen Betts created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1411 I think this is a documentation problem, not a code problem. ## Description of problem: gnutls_ext_raw_parse() unexpectedly returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE ## Version of gnutls used: 3.7.1-5+deb11u2 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian ## How reproducible: Steps to Reproduce: send a client_hello packet containig no extensions, eg: this one (hex): 16030000430100003f0302ffffffff923e9988d02b8fc276bdcf02ccb6fc3900 d052828c650ccd8c0200400000180033003900450088001600350084002f0041 000a000500040100 ## Actual results: it returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE ## Expected results: I was expecting GNUTLS_E_SUCCESS -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1411 You're receiving 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 Oct 3 11:27:04 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Oct 2022 09:27:04 +0000 Subject: [gnutls-devel] GnuTLS | Make XTS key check failure not fatal (!1648) In-Reply-To: References: Message-ID: All discussions on merge request !1648 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1648 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1648 You're receiving 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 Oct 3 12:16:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Oct 2022 10:16:47 +0000 Subject: [gnutls-devel] GnuTLS | Make XTS key check failure not fatal (!1648) In-Reply-To: References: Message-ID: Merge request !1648 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1648 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1648 You're receiving 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 Oct 3 12:16:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Oct 2022 10:16:47 +0000 Subject: [gnutls-devel] GnuTLS | Library becomes unusable after XTS key check fails in FIPS (#1408) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via merge request !1648 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1648) Issue #1408: https://gitlab.com/gnutls/gnutls/-/issues/1408 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1408 You're receiving 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 Oct 4 08:39:24 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Oct 2022 06:39:24 +0000 Subject: [gnutls-devel] GnuTLS | Discussion: tarball signing practice (#1407) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: Would it be a problem if we limit keys that are in the release keyring to gnutls maintainers? Even if the release is done by somebody else? That would help reduce the overhead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1407#note_1123198560 You're receiving 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 Oct 4 12:05:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Oct 2022 10:05:49 +0000 Subject: [gnutls-devel] GnuTLS | Segfault during handshake on server connection if no private key is supplied (#1412) References: Message-ID: Sebastian Dr?ge created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1412 When providing credentials without a private key then `gnutls_handshake()` will segfault. This is obviously an application bug but it would be great if GnuTLS could also catch this in a better way, either with an actual assertion or with a handshake error. valgrind reports the following with the attached server application (based on the echo server example from the docs): ``` ==427258== Invalid read of size 4 ==427258== at 0x490617D: _gnutls_privkey_compatible_with_sig (privkey.c:1966) ==427258== by 0x499BD22: _gnutls_session_get_sign_algo (signature.c:381) ==427258== by 0x49A94BC: cert_select_sign_algorithm (cert.c:1591) ==427258== by 0x49AC308: _gnutls_select_server_cert (cert.c:1643) ==427258== by 0x49B778D: _gnutls_figure_common_ciphersuite (ciphersuites.c:1526) ==427258== by 0x48D01C1: _gnutls_server_select_suite (handshake.c:1158) ==427258== by 0x48D2FBC: read_client_hello (handshake.c:862) ==427258== by 0x48D2FBC: _gnutls_recv_handshake (handshake.c:1641) ==427258== by 0x48D6368: handshake_server (handshake.c:3496) ==427258== by 0x48D6368: gnutls_handshake (handshake.c:2886) ==427258== by 0x1097B0: main (test.c:127) ==427258== Address 0x4 is not stack'd, malloc'd or (recently) free'd ``` Testcase application ```cpp #include #include #include #include #include #include #include #include #include #include #include #include #include #define CHECK(x) assert((x) >= 0) #define LOOP_CHECK(rval, cmd) \ do { \ rval = cmd; \ } while (rval == GNUTLS_E_AGAIN || rval == GNUTLS_E_INTERRUPTED) #define MAX_BUF 1024 #define PORT 5556 const unsigned char cert_data[] = "-----BEGIN CERTIFICATE----- \ MIIEQDCCAqigAwIBAgIRAO5XT7tkYlNt77CBj2H5HiEwDQYJKoZIhvcNAQELBQAw \ czEeMBwGA1UEChMVbWtjZXJ0IGRldmVsb3BtZW50IENBMSQwIgYDVQQLDBtqbWFs \ dmVzQHBvcC1vcyAoSm9hbyBBbHZlcykxKzApBgNVBAMMIm1rY2VydCBqbWFsdmVz \ QHBvcC1vcyAoSm9hbyBBbHZlcykwHhcNMjIwOTIyMTIyNTMzWhcNMjQxMjIyMTMy \ NTMzWjBPMScwJQYDVQQKEx5ta2NlcnQgZGV2ZWxvcG1lbnQgY2VydGlmaWNhdGUx \ JDAiBgNVBAsMG2ptYWx2ZXNAcG9wLW9zIChKb2FvIEFsdmVzKTCCASIwDQYJKoZI \ hvcNAQEBBQADggEPADCCAQoCggEBAJPz8CCFHtNsSzbc64tR/7B1Kf1xuxDz0cBS \ vAlEYzfaBrPmgV3zoaIgKnW9u8EWwvRXzhVLfMnO/x8jfIRmSDDK1M+fXmriIDkx \ 5cbWnCN2GQ81P/GdvsGpx2XWBpKTCYQm/6EvdvAsg0+GWrgSxo4hFg59YLaWeWHj \ PTSKABM9C63X9UnQKvP25rYkJ42znnkmqmGXCe1iPk1xZvDfqcbZ1sZXlMV2dS9M \ CRu6Dwqo7N3hVbwM/vZ4X7vWH6JRT8Soz6CijWDcAVvusrxx0QyNQg4nuQznZrnW \ nQbjmEQf4MCO4OCd5uh5rXcxvdYZbpMx25EujMbh0OWfecC+GH8CAwEAAaNzMHEw \ DgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB8GA1UdIwQYMBaA \ FIwNqPZz6OxXFjHo/y0pAHyU3Q2TMCkGA1UdEQQiMCCCCWxvY2FsaG9zdIINZHMu \ YWl2ZXJvLmxhbocEfwAAATANBgkqhkiG9w0BAQsFAAOCAYEAiPa2QzuPK9FckgW+ \ FBu0fwsjBY+DOhhLzj7Su2eEg0hQDuV8A8hwbj6lfvY0UGOh6Tb6fjs/daUaQLcK \ k5och7JbHiauch5hVx2xmXCcJu55sLW9UcJHOSvP+jalUm1BqlMWHIAcbFwajOWV \ tXENgRleSkFmw2uoi66lQq8QBHDosUKJukZQnweXihWXoZ2pWPkaOY3cBc2DYpBM \ 8ioyW6mdyG1Ot4vT5En+WauGJCFKAzvPtM74HNp9kw+ddLqPamTTbMtm78gi8B7E \ eHPYBedjEvaroY5lw1iU6n5VNiF61Ygc3vC4QSCIBNOOMUEXwK0c3gzF9DrpCBXY \ ezVYCmgnM5FfeJ/l25DhpPdUTD+MJJ3dZd+AB4Kx7a0dI5xWelaZCExa+yr8UWYd \ hsrOnFMTWHMjlx+kzWxC4U+bHAxX4buQpq37l9GyASldbLGdqA86Dnaxit3nhZPb \ GO+ToIks+22GnP8wLvWWTZc3wV90RhRDy5GkZzDX7K8J1/C0 \ -----END CERTIFICATE-----"; static const gnutls_datum_t cert_pem = { .data = (unsigned char *)cert_data, .size = sizeof(cert_data), }; static gnutls_x509_crt_t cert; static gnutls_privkey_t privkey; static gnutls_certificate_credentials_t creds; static int retrieve_func(gnutls_session_t session, const gnutls_datum_t *req_ca_rdn, int nreqs, const gnutls_pk_algorithm_t *pk_algos, int pk_algos_length, gnutls_pcert_st **pcert, unsigned int *pcert_length, gnutls_privkey_t *pkey) { *pcert = malloc(sizeof(gnutls_pcert_st)); gnutls_pcert_import_x509(*pcert, cert, 0); *pcert_length = 1; *pkey = *pkey; return 0; } int main(void) { int listen_sd; int sd, ret; gnutls_priority_t priority_cache; struct sockaddr_in sa_serv; struct sockaddr_in sa_cli; socklen_t client_len; char topbuf[512]; gnutls_session_t session; char buffer[MAX_BUF + 1]; int optval = 1; CHECK(gnutls_global_init()); CHECK(gnutls_x509_crt_init(&cert)); CHECK(gnutls_x509_crt_import(cert, &cert_pem, GNUTLS_X509_FMT_PEM)); CHECK(gnutls_privkey_init(&privkey)); CHECK(gnutls_certificate_allocate_credentials(&creds)); gnutls_certificate_set_retrieve_function2(creds, retrieve_func); CHECK(gnutls_priority_init(&priority_cache, NULL, NULL)); listen_sd = socket(AF_INET, SOCK_STREAM, 0); memset(&sa_serv, '\0', sizeof(sa_serv)); sa_serv.sin_family = AF_INET; sa_serv.sin_addr.s_addr = INADDR_ANY; sa_serv.sin_port = htons(PORT); /* Server Port number */ setsockopt(listen_sd, SOL_SOCKET, SO_REUSEADDR, (void *)&optval, sizeof(int)); bind(listen_sd, (struct sockaddr *)&sa_serv, sizeof(sa_serv)); listen(listen_sd, 1024); printf("Server ready. Listening to port '%d'.\n\n", PORT); client_len = sizeof(sa_cli); for (;;) { CHECK(gnutls_init(&session, GNUTLS_SERVER)); CHECK(gnutls_priority_set(session, priority_cache)); CHECK(gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, creds)); gnutls_certificate_server_set_request(session, GNUTLS_CERT_IGNORE); gnutls_handshake_set_timeout(session, GNUTLS_DEFAULT_HANDSHAKE_TIMEOUT); sd = accept(listen_sd, (struct sockaddr *)&sa_cli, &client_len); printf("- connection from %s, port %d\n", inet_ntop(AF_INET, &sa_cli.sin_addr, topbuf, sizeof(topbuf)), ntohs(sa_cli.sin_port)); gnutls_transport_set_int(session, sd); LOOP_CHECK(ret, gnutls_handshake(session)); if (ret < 0) { close(sd); gnutls_deinit(session); fprintf(stderr, "*** Handshake has failed (%s)\n\n", gnutls_strerror(ret)); continue; } printf("- Handshake was completed\n"); for (;;) { LOOP_CHECK(ret, gnutls_record_recv(session, buffer, MAX_BUF)); if (ret == 0) { printf("\n- Peer has closed the GnuTLS connection\n"); break; } else if (ret < 0 && gnutls_error_is_fatal(ret) == 0) { fprintf(stderr, "*** Warning: %s\n", gnutls_strerror(ret)); } else if (ret < 0) { fprintf(stderr, "\n*** Received corrupted " "data(%d). Closing the connection.\n\n", ret); break; } else if (ret > 0) { CHECK(gnutls_record_send(session, buffer, ret)); } } printf("\n"); LOOP_CHECK(ret, gnutls_bye(session, GNUTLS_SHUT_WR)); close(sd); gnutls_deinit(session); } close(listen_sd); gnutls_x509_crt_deinit(cert); gnutls_privkey_deinit(privkey); gnutls_certificate_free_credentials(creds); gnutls_priority_deinit(priority_cache); gnutls_global_deinit(); return 0; } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1412 You're receiving 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 Oct 4 16:38:56 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Oct 2022 14:38:56 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) References: Message-ID: Zolt?n Fridrich created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Closes #1378 ## 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/1650 You're receiving 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 Oct 4 16:38:55 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Oct 2022 14:38:55 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Reassigned merge request 1650 https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 5 11:31:54 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 09:31:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball has almost empty AUTHORS file (#1409) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: I think this is what happened: https://gitlab.com/gnutls/gnutls/-/blob/3.7.8/Makefile.am#L70 ``` GEN AUTHORS fatal: using multiple --group options with stdin is not supported ``` This invocation should be fixed to both work and to fail harder when it doesn't. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1409#note_1124854898 You're receiving 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 Oct 5 14:48:46 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 12:48:46 +0000 Subject: [gnutls-devel] GnuTLS | WIP: KTLS key update support (!1625) In-Reply-To: References: Message-ID: All discussions on merge request !1625 were resolved by Franti?ek Kren?elok https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 You're receiving 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 Oct 5 16:34:09 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 14:34:09 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Looks OK to me. Nitpick: I'd prefer approved/unapproved results to be hardcoded outside of `test_pbkdf2`, not deduced inside it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643#note_1125326631 You're receiving 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 Oct 5 16:34:17 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 14:34:17 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: Merge request !1643 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643 Project:Branches: dueno/gnutls:wip/dueno/symkey-limit 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/1643 You're receiving 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 Oct 5 17:33:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 15:33:43 +0000 Subject: [gnutls-devel] GnuTLS | fips: fix checking on hash algorithm used in ECDSA (!1644) In-Reply-To: References: Message-ID: Merge request !1644 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1644 Project:Branches: dueno/gnutls:wip/dueno/ecdsa-hash-check 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/1644 You're receiving 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 Oct 5 18:26:23 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 16:26:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball has almost empty AUTHORS file (#1409) In-Reply-To: References: Message-ID: Andreas Metzler commented: Do you have any idea why this restriction in git exists? ~~~ *prompt*: git shortlog -sen --no-merges --group author --group trailer:co-authored-by < /dev/null > /dev/null fatal: using multiple --group options with stdin is not supported ~~~ I really do not get why this is related to stdin redirection. I also could not find this being documented. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1409#note_1125520485 You're receiving 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 Oct 5 23:54:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 21:54:49 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.0 (Oct 1, 2022?Nov 15, 2022) ( https://gitlab.com/gnutls/gnutls/-/milestones/30 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 You're receiving 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 Oct 5 23:55:18 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 21:55:18 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Merge request !1625 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 Project:Branches: FrantisekKrenzelok/gnutls:wip/ktls_keyupdate to gnutls/gnutls:master Author: Franti?ek Kren?elok Assignee: Franti?ek Kren?elok Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 You're receiving 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 Oct 5 23:55:45 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 21:55:45 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Daiki Ueno commented: Great work, thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1125864211 You're receiving 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 Oct 5 23:56:36 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 21:56:36 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Merge request !1625 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 Project:Branches: FrantisekKrenzelok/gnutls:wip/ktls_keyupdate to gnutls/gnutls:master Author: Franti?ek Kren?elok Assignee: Franti?ek Kren?elok Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 You're receiving 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 Oct 6 00:33:52 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 22:33:52 +0000 Subject: [gnutls-devel] GnuTLS | fips: fix checking on hash algorithm used in ECDSA (!1644) 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/1644#note_1125886987 You're receiving 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 Oct 6 00:34:03 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 22:34:03 +0000 Subject: [gnutls-devel] GnuTLS | fips: fix checking on hash algorithm used in ECDSA (!1644) In-Reply-To: References: Message-ID: Merge request !1644 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1644 Project:Branches: dueno/gnutls:wip/dueno/ecdsa-hash-check to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1644 You're receiving 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 Oct 6 01:13:29 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Oct 2022 23:13:29 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: toidiu commented: Hello following this work and had a few questions: I dont know if I missed it but is it possible to share the kernel patch which accompanies this change. Also its not clear to me if how exactly the new key_update functionality is detected. Specifically, I am having trouble telling what the new functionality is (previous we ignored all post handshake message right). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1125913169 You're receiving 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 Oct 6 10:22:21 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 06 Oct 2022 08:22:21 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1126283476 Hi, Regarding the patch, I will check with the author. As to the functionality we indeed ignored all posth-handshake messages, but now when TLS_HANDSHAKE messages are received they are feeded to gnutls for processing via [gnutls_handshake_write()](https://www.gnutls.org/manual/gnutls.html#index-gnutls_005fhandshake_005fwrite). GnuTLS derives new keys and sends them to kernel via [_gnutls_ktls_set_keys()](https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/ktls.c#L83) then sends the key_update message to the peer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1126283476 You're receiving 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 Oct 7 09:44:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Oct 2022 07:44:16 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) 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/1650 You're receiving 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 Oct 7 10:04:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Oct 2022 08:04:00 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Richard W_M_ Jones commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1127691559 I have a few comments: What is merged in gnutls is not a complete fix, right? It seems like the new handshake function just returns an unimplemented error. Are there further proposed merge requests connected to this one? Also I would like to see the kernel patch that is associated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1127691559 You're receiving 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 Oct 7 12:36:08 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Oct 2022 10:36:08 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1127952664 This is a complete fix for keyupdate. The only ocasion in which unimplemented error should occur is when `ENABLE_KTLS` is not defined. Please check the gnutls configuration for '--enable-ktls' option -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1127952664 You're receiving 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 Oct 7 15:12:46 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Oct 2022 13:12:46 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Reassigned Issue 1335 https://gitlab.com/gnutls/gnutls/-/issues/1335 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335 You're receiving 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 Oct 7 15:12:53 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Oct 2022 13:12:53 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.0 (Oct 1, 2022?Nov 15, 2022) ( https://gitlab.com/gnutls/gnutls/-/milestones/30 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335 You're receiving 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 Oct 10 20:04:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Oct 2022 18:04:00 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: toidiu commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1130448216 I had a few clarifying question on what the expected behavior: - prior to this change, since we ignored handshake msg, does that mean the connection fails when the peer sends a key_update? - since this change requires a kernel patch; what happens if the kernel patch is NOT applied but ktls is enabled? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1130448216 You're receiving 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 Oct 11 08:09:55 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 06:09:55 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1130873460 > int ret; > > + if (session->internals.priorities->no_status_request) Do we need this check? If `GNUTLS_NO_STATUS_REQUEST` is supplied to `gnutls_init`, `gnutls_ocsp_status_request_enable_client` is not called and thus the following `epriv == NULL` holds. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 11 08:11:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 06:11:28 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1130874834 > status_request_ext_st *priv; > int ret; > > + if (session->internals.priorities->no_status_request) Sigh, disregard this comment. I've updated it with lengthier explanation but the web interface swallowed it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1130874834 You're receiving 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 Oct 11 08:11:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 06:11:28 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: All discussions on merge request !1650 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 11 08:15:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 06:15:14 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1130878303 > status_request_ext_st *priv; > int ret; > > + if (session->internals.priorities->no_status_request) So what I wanted to write was: We now have 3 places to check whether status_request is enabled: - `session->internals.priorities->no_status_request` (set by priority string) - `session->internals.flags & GNUTLS_NO_STATUS_REQUEST` (set by `gnutls_init`) - `_gnutls_hello_ext_get_priv(session, GNUTLS_EXTENSION_STATUS_REQUEST, &epriv);` (set by `gnutls_ocsp_status_request_enable_client`) Can we consolidate them? I find `session->internals.flags & GNUTLS_NO_STATUS_REQUEST` the most obvious among others. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1130878303 You're receiving 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 Oct 11 16:55:21 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 14:55:21 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1131680058 > status_request_ext_st *priv; > int ret; > > + if (session->internals.priorities->no_status_request) I have removed the checks from the recv functions and have moved the checks from lib/handshake.c into the lib/ext/status_request.c There are pretty much only 4 checks now. - 2 checks for the send functions inside lib/ext/status_request.c - check for the flag in gnutls_init - check in lib/x509/certificate.c for the cert extension I am not sure how to consolidate this further. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1131680058 You're receiving 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 Oct 11 19:49:18 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Oct 2022 17:49:18 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1131944240 >prior to this change, since we ignored handshake msg, does that mean the connection fails when the peer sends a key_update? Yes, that is correct >since this change requires a kernel patch; what happens if the kernel patch is NOT applied but ktls is enabled? KTLS will be used until key_update is received or send, after that it will be disabled and GnuTLS will fallback to default i.e. gnutls will handle encryption and decryption -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1131944240 You're receiving 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 Oct 12 02:37:30 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 12 Oct 2022 00:37:30 +0000 Subject: [gnutls-devel] GnuTLS | The GNUTLS Release 3.3.16 has a bug in the DTLS Non-Blocking logic, bug located at gnutls-3.6.16/lib/record.c in function _gnutls_recv_in_buffers at lines 1307 and 1322 (#1413) References: Message-ID: Chuck Wanner created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1413 ## Description of problem: We are currently using the GNUTLS Library for a DTLS Server and Client. Our design requires the GNUTLS_NONBLOCK flag to be set. We wrote our DTLS Software back in 2018 and 2019. We were using GNUTLS version 3.3.26 without any issues. We are stepping up to Redhat 8 which is using GNUTLS Version 3.6.16. We configure the DTLS Client and Server to be non-blocking, but our GNUTLS Pull Timeout function is never invoked. Only the GNUTLS Pull Function is invoked. I believe the issue that we are encountering is a logic error in gnutls-3.6.16/lib/record.c in function _gnutls_recv_in_buffers at lines 1307 and 1322. For example at line 1307: ret = recv_headers(session, record_params, type, htype, &record, (!(session->internals.flags & GNUTLS_NONBLOCK))?&ms:0); When the GNUTLS_NONBLOCK flag is set, the recv_headers will expect the pointer to the timeout value to be set. But this line will always pass NULL when the GNUTLS_NONBLOCK flag is set. I believe the solution to the problem should be remove the not logic. The fix for line 1307: ret = recv_headers(session, record_params, type, htype, &record, (session->internals.flags & GNUTLS_NONBLOCK)?&ms:0); The same issue exists at line 1322: /* Read the packet data and insert it to record_recv_buffer. */ ret = _gnutls_io_read_buffered(session, record.packet_size, record.type, (!(session->internals.flags & GNUTLS_NONBLOCK))?&ms:0); The fix for line 1322: /* Read the packet data and insert it to record_recv_buffer. */ ret = _gnutls_io_read_buffered(session, record.packet_size, record.type, (session->internals.flags & GNUTLS_NONBLOCK)?&ms:0); Note: There are a number of locations where the GNUTLS_NONBLOCK flag is used. I did not review the other locations to determine if there is an issue. Note: I did verify the same logic still exists in GNUTLS Version 3.7.8. Below is some of our code sections initializing the GNUTLS Library. At the start we invoke the following: /* ** Initialize the GNU TLS DTLS Session */ gnutls_ret_code = gnutls_init(&mpGnuTlsSession, GNUTLS_SERVER | GNUTLS_DATAGRAM | GNUTLS_NONBLOCK); We setup private data, pull functions, and push functions: /* ** Provide the UDP Socket to the GNU TLS DTLS Server ** ** Note: No return value */ gnutls_transport_set_ptr(this->mpGnuTlsSession, &this->mPrivateData); gnutls_transport_set_push_function(this->mpGnuTlsSession, gnutlsPushFunction); gnutls_transport_set_pull_function(this->mpGnuTlsSession, gnutlsPullFunction); gnutls_transport_set_pull_timeout_function(this->mpGnuTlsSession, gnutlsPullTimeoutFunction); After the Handshake is complete, we invoke the following to configure the Timeout: /* ** Set the Receive Timeout for the Application Data ** ** Note: No return value */ gnutls_record_set_timeout(this->mpGnuTlsSession, cDtlsTimeoutMs); We invoke the following to process the application data sent from the DTLS Client or Server: /* ** Check to see if message is available */ gnutls_recv_status = gnutls_record_recv_seq(this->mpGnuTlsSession, (void *)mRcvBuffer, cDtlsRecvMaxBufferSize, sequence); We verified that the GNUTLS Pull Timeout function is never invoked. Only the GNUTLS Pull function is invoked. ## Version of gnutls used: Version 3.3.16 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) RHEL 8 ## How reproducible: Configure the DTLS Server or Client with the GNUTLS_NONBLOCK flag. Configure the DTLS Server or Client with the pull and pull timeout functions with log statements to verify when they are called. Set the timeout with function gnutls_record_set_timeout. After the handshake is complete between the server and client, invoke gnutls_record_recv_seq. Steps to Reproduce: * one * two * three ## Actual results: With the logging in the Pull functions, you will only see the GNUTLS Pull function invoked. The GNUTLS Pull Timeout function is never invoked. ## Expected results: With the logging in the Pull functions, you should see the GNUTLS Pull Timeout function invoked. The GNUTLS Pull function should be invoked if the GNUTLS Pull Timeout has determine data is available. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1413 You're receiving 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 Oct 12 15:57:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 12 Oct 2022 13:57:00 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651 Project:Branches: jas/gnutls:jas/drop-guile to gnutls/gnutls:master Author: Simon Josefsson A first attempt at dropping guile stuff from core GnuTLS repository. What do you think? ## 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/1651 You're receiving 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 Oct 13 02:06:27 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 00:06:27 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 was reviewed by Daiki Ueno -- Daiki Ueno commented on a discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1133827809 > int ret; > > + if (session->internals.priorities->no_status_request) nit: I still think it would be nice to use `session->internals.flags` throughout the code, as `%NO_TICKETS` is [propagated](https://gitlab.com/gnutls/gnutls/-/blob/f5dcbdb46df52458e3756193c2a23bf558a3ecfd/lib/priority.c#L685) to `session->internals.flags` in `gnutls_priority_set`. -- Daiki Ueno started a new discussion on doc/cha-gtls-app.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1133827811 > > + at item %NO_STATUS_REQUEST @tab > +will prevent sending of the TLS status_request extension in client side. There is an inconsistency between the doc and the code: while the doc says "in client side", `%NO_STATUS_REQUEST` actually causes the server to not send the empty `status_request` extension in Server Hello; as `session->internals.priorities->no_status_request` is checked at the beginning of `_gnutls_status_request_send_params`. I think it would make sense to limit the effect of the option to client only, because on the server side it is only enabled through `gnutls_certificate_set_ocsp_status_request_function*`. -- Daiki Ueno started a new discussion on lib/ext/status_request.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1133827813 > > - if (!(session->internals.hsk_flags & HSK_OCSP_REQUESTED)) > + if (session->internals.priorities->no_status_request || If we limit the effect of `%NO_STATUS_REQUEST` to client only, this check wouldn't be necessary. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 13 05:47:08 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 03:47:08 +0000 Subject: [gnutls-devel] GnuTLS | The GNUTLS Release 3.3.16 has a bug in the DTLS Non-Blocking logic, bug located at gnutls-3.6.16/lib/record.c in function _gnutls_recv_in_buffers at lines 1307 and 1322 (#1413) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks like this is the first commit that changed the behavior: https://gitlab.com/gnutls/gnutls/-/commit/2a46a94fab312f584db071bc23668c942f8e439e#262a8c0db6e7caeff5570034957c36922727d5b7_1157_1156 This aligns with the documentation of `gnutls_transport_set_pull_timeout_function`, which says: "The callback will not be used when the session is **in TLS mode** with non-blocking sockets." Perhaps we should conditionalize it based on which TLS or DTLS is used? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1413#note_1133976820 You're receiving 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 Oct 13 13:25:13 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 11:25:13 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: All discussions on merge request !1650 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 13 15:43:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 13:43:10 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1134744464 > renegotiation thus this option must be used with care. When this option > is set no versions later than TLS1.2 can be negotiated. > > + at item %NO_STATUS_REQUEST @tab > +will prevent sending of the TLS status_request extension in client side. This is still not covered: the check is too early in `_gnutls_status_request_send_params`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1134744464 You're receiving 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 Oct 13 15:55:48 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 13:55:48 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on doc/cha-gtls-app.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1134765014 > renegotiation thus this option must be used with care. When this option > is set no versions later than TLS1.2 can be negotiated. > > + at item %NO_STATUS_REQUEST @tab > +will prevent sending of the TLS status_request extension in client side. Right, I get what you meant now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1134765014 You're receiving 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 Oct 13 16:10:46 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 14:10:46 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: All discussions on merge request !1650 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 13 18:57:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 16:57:16 +0000 Subject: [gnutls-devel] GnuTLS | The GNUTLS Release 3.3.16 has a bug in the DTLS Non-Blocking logic, bug located at gnutls-3.6.16/lib/record.c in function _gnutls_recv_in_buffers at lines 1307 and 1322 (#1413) In-Reply-To: References: Message-ID: Chuck Wanner commented: I was reading the documentation for the `gnutls_transport_set_pull_timeout_function` and `gnutls_transport_set_pull_function`. I am a bit confused. If the `GNUTLS_NONBLOCK` flag is set, the documentation indicates the pull timeout callback will not be invoked. But the `gnutls_transport_set_pull_function` indicates that the pull callback should only return when data is received (number of bytes received), the connection is terminated (return 0), or connection error (return -1). The pull function does not have a return value to indicate there is no data and the connection is valid. How is GNUTLS consider non-blocking, if only the pull function is invoked? The `gnutls_transport_set_pull_timeout_function` documentation indicates if the timeout is zero, the function should return 0 immediately if no data is available. I do not think this is correct. Reviewing the code, if the timeout is zero the pull timeout function will not be invoked. The pull function is invoked which will pend forever until data is received, the connection is terminated, or the connection has an error. In the gnutls-3.6.16/lib/buffers.c, function `_gnutls_dgram_read` at line 251 will not invoke the pull timeout function if the timeout is zero. ``` if (ms && *ms > 0) { ret = _gnutls_io_check_recv(session, *ms); if (ret < 0) return gnutls_assert_val(ret); gnutls_gettime(&t1); } *bufel = _mbuffer_alloc_align16(max_size, get_total_headers(session)); if (*bufel == NULL) return gnutls_assert_val(GNUTLS_E_MEMORY_ERROR); ptr = (*bufel)->msg.data; reset_errno(session); i = pull_func(fd, ptr, recv_size); ``` Note: Function `_gnutls_io_check_recv` invokes the Pull Timeout function ``` /* Checks whether there are received data within * a timeframe. * * Returns 0 if data were received, GNUTLS_E_TIMEDOUT * on timeout and a negative error code on error. */ int _gnutls_io_check_recv(gnutls_session_t session, unsigned int ms) { gnutls_transport_ptr_t fd = session->internals.transport_recv_ptr; int ret = 0, err; if (NO_TIMEOUT_FUNC_SET(session)) { _gnutls_debug_log("The pull function has been replaced but not the pull timeout.\n"); return gnutls_assert_val(GNUTLS_E_PULL_ERROR); } reset_errno(session); ret = session->internals.pull_timeout_func(fd, ms); if (ret == -1) { err = get_errno(session); _gnutls_read_log ("READ_TIMEOUT: %d returned from %p, errno=%d (timeout: %u)\n", (int) ret, fd, err, ms); return errno_to_gerr(err, IS_DTLS(session)); } if (ret > 0) return 0; else return GNUTLS_E_TIMEDOUT; } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1413#note_1135039277 You're receiving 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 Oct 13 21:07:46 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 19:07:46 +0000 Subject: [gnutls-devel] GnuTLS | The GNUTLS Release 3.6.16 has a bug in the DTLS Non-Blocking logic, bug located at gnutls-3.6.16/lib/record.c in function _gnutls_recv_in_buffers at lines 1307 and 1322 (#1413) In-Reply-To: References: Message-ID: Andy Zhang commented: The Version of gnutls used is 3.6.16 (not 3.3.16) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1413#note_1135172118 You're receiving 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 Oct 13 21:14:45 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 19:14:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) References: Message-ID: Eric Blake created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 Project:Branches: ebblake/gnutls:master to gnutls/gnutls:master Author: Eric Blake 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 * [X] 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/1652 You're receiving 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 Oct 13 21:26:56 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Oct 2022 19:26:56 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: I am not sure how to go about adding testsuite coverage for this one. At some point, gnutls might want to consider marking gnutls_init with __attribute__((__malloc__, __malloc__(gnutls_deinit, 1))) so that code analyzers can more obviously spot bugs like calling free(session) or forgetting to call gnutls_deinit(session), but that is beyond the scope of this patch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1135190064 You're receiving 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 Oct 14 11:23:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 09:23:00 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Daiki Ueno commented: I still have a couple of concerns: - what happens if `gnutls_init` is called with GNUTLS_NO_STATUS_REQUEST, but later it is enabled through `gnutls_ocsp_status_request_enable_client` (or also with priority string)? - RFC6066 section 8 says: "Note in addition that a server MUST NOT send the "CertificateStatus" message unless it received a "status_request" extension in the client hello message and sent a "status_request" extension in the server hello message"; are we sure all those checks are in place? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1135801484 You're receiving 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 Oct 14 12:47:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 10:47:14 +0000 Subject: [gnutls-devel] guile-gnutls | New release: Guile-GnuTLS 3.7.9 - v3.7.9 Message-ID: A new Release v3.7.9 for guile-gnutls was published. Visit the Releases page to read more about it: https://gitlab.com/gnutls/guile/-/releases Assets: - Download zip: https://gitlab.com/gnutls/guile/-/archive/v3.7.9/guile-v3.7.9.zip - Download tar.gz: https://gitlab.com/gnutls/guile/-/archive/v3.7.9/guile-v3.7.9.tar.gz - Download tar.bz2: https://gitlab.com/gnutls/guile/-/archive/v3.7.9/guile-v3.7.9.tar.bz2 - Download tar: https://gitlab.com/gnutls/guile/-/archive/v3.7.9/guile-v3.7.9.tar Release notes: https://gitlab.com/gnutls/guile/-/blob/d1624ef288a492d0bbb9effcd26650dfeed4f8e9/NEWS [guile-gnutls-3.7.9.tar.gz.sig](/uploads/9ee831010aea06adb1dd6ec78973b5d9/guile-gnutls-3.7.9.tar.gz.sig) [guile-gnutls-3.7.9.tar.gz](/uploads/b4d5cb4e4394ef8eaa56bfb0edad3c08/guile-gnutls-3.7.9.tar.gz) -- View it on GitLab: https://gitlab.com/gnutls/guile/-/releases You're receiving 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 Oct 14 12:57:32 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 10:57:32 +0000 Subject: [gnutls-devel] guile-gnutls | Use gnulib? (#1) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/1 This would avoid the manual copies of some files (config.rpath, lib-*.m4 etc), scripts for a web manual, and automated release scripts. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/1 You're receiving 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 Oct 14 12:58:22 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 10:58:22 +0000 Subject: [gnutls-devel] guile-gnutls | Build failure on AlmaLinux (#2) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/2 How to install guile on this platform? See https://gitlab.com/gnutls/guile/-/jobs/3173772697 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/2 You're receiving 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 Oct 14 12:59:12 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 10:59:12 +0000 Subject: [gnutls-devel] guile-gnutls | Centos7 build failures (#3) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/3 Looks like source-code related problem? Too old guile/gnutls? https://gitlab.com/gnutls/guile/-/jobs/3173772695 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/3 You're receiving 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 Oct 14 13:00:26 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 11:00:26 +0000 Subject: [gnutls-devel] guile-gnutls | SRP build option (#4) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/4 Right now there is a --disable-srp-authentication ./configure switch, inherited from GnuTLS. It should be handled better. Should SRP support be auto-detected during build-time? Can it be detected during guile runtime? Other ideas? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/4 You're receiving 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 Oct 14 13:01:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 11:01:14 +0000 Subject: [gnutls-devel] guile-gnutls | Indent code (#5) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/5 Does 'indent' handle Guile code? We should run it on C code anyway. Gnulib has some rules for this, see #1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/5 You're receiving 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 Oct 14 13:02:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 11:02:47 +0000 Subject: [gnutls-devel] guile-gnutls | Deprecation warnings? (#6) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/guile/-/issues/6 The build output complains about deprecated symbols, are these real problems? ``` enums.h:199:1: warning: 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations] enum-map.i.c:199:3: warning: 'gnutls_compression_get_name' is deprecated [-Wdeprecated-declarations] ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/6 You're receiving 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 Oct 14 15:41:06 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 13:41:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) 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/1653 You're receiving 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 Oct 14 15:41:07 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 13:41:07 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) References: Message-ID: Zolt?n Fridrich created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel3 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno Closes #1335 ## 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/1653 You're receiving 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 Oct 14 15:41:06 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 13:41:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Reassigned merge request 1653 https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 14 15:47:24 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 13:47:24 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1335#note_1136175090 Thank you, this was really helpful. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335#note_1136175090 You're receiving 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 Oct 14 15:52:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 13:52:16 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: I was able to reproduce and fix this issue in !1653. Below I am attaching two certs where x.pem contains duplicate and y.pem doesn't. To reproduce this bug use: `certtool --infile=x.pem --verify` [x.pem](/uploads/19a946d1c252c182c9388551d53e7f0f/x.pem) [y.pem](/uploads/1de1ee34c8ebcc45d650e39e6ed7a7bb/y.pem) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335#note_1136181407 You're receiving 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 Oct 14 16:09:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 14:09:10 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1136207324 - enabling the extension later when it was first disabled would currently not work. Should be a very easy fix if we want to allow this, also with priority string - RFC6066, I am not sure about that, I will have to check -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1136207324 You're receiving 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 Oct 14 16:10:29 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 14:10:29 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) In-Reply-To: References: Message-ID: Simon Josefsson commented: Guile-GnuTLS 3.7.9 has been released now, and I re-read this MR and it is looking good to me. Could someone please review this? Should reduce CI/CD build time and GnuTLS source code tree complexity a bit. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651#note_1136208999 You're receiving 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 Oct 14 16:48:21 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 14:48:21 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (#1415) References: Message-ID: Tim Kosse created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1415 Some tools, for example win-acme, create encrypted private keys in OpenSSL's traditional format containing lowercase hex digits in the IV part of the DEK-Info PEM header. These key files are accepted by OpenSSL. Prior to this patch, GnuTLS did reject these keys with GNUTLS_E_INVALID_REQUEST. [0001-Handle-private-keys-with-lowercase-hex-digits-in-DEK.patch](/uploads/565a5d48eff7b90a68feef4ae33a293d/0001-Handle-private-keys-with-lowercase-hex-digits-in-DEK.patch) PS: I cannot send merge requests, the e-mail addresses generated by Gitlab are not in a format accepted by 'git send-email' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1415 You're receiving 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 Oct 14 18:11:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 16:11:47 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: See also issue #1414. The fix proposed so far is incomplete - gnutls_init() has exit paths where *session is modified to the result of calloc() that has later been passed to gnutls_deinit(), which is a stale pointer. Since there is code in the wild that DOES call gnutls_deinit() on this stale pointer, that is a double-free. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1136363080 You're receiving 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 Oct 14 21:14:41 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 19:14:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: I've updated the patches to do a full audit of all gnutls_*_init(gnutls_*_t *var,...) functions, and fixed a couple other things I noticed in the process. Given the inconsistent mix (some never touched *var except on success, some always set *var on all exit paths, and some were timebombs for double-free if the client blindly assumes calling gnutls_*_deinit(var) was safe on failure), and the existence of code in the wild that assumes unconditional deinit is safe, it was easier to make ALL init functions consistently set a sane value on all exit paths than to try and document which ones are time-bombs. However, we may still want more documentation changes (copying what I added for gnutls_init() into other *_init functions or into a more centralized overview portion of the manual). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1136528517 You're receiving 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 Oct 14 22:21:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Oct 2022 20:21:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: regarding my earlier comment about __attribute__ malloc - it won't quite work (the _init functions don't return the malloc'd pointer, but instead assign it into an output parameter) - maybe the gcc folks will have better ideas of how to annotate pointers allocated in gnutls' style while still being able to track that the resulting variable is passed to the correct deinit function. But as mentioned before, that's a different project than fixing the existing risk of client double-free bugs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1136577533 You're receiving 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 Oct 15 13:50:36 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 15 Oct 2022 11:50:36 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Andreas Metzler commented: The patch fixes the testcase I provided in the original report. Some cert has expired so one now needs datefudge: ~~~ used to fail but should not: datefudge 2022-03-01 certtool --infile=/tmp/ci.pem --verify --load-ca-certificate=/etc/ssl/certs/ISRG_Root_X1.pem duplicate cert removed, succeded datefudge 2022-03-01 certtool --infile=/tmp/ci-noduplicate.pem --verify --load-ca-certificate=/etc/ssl/certs/ISRG_Root_X1.pem ~~~ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335#note_1136833552 You're receiving 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 Oct 16 01:19:27 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 15 Oct 2022 23:19:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/x509/crl.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1136952436 > gnutls_assert(); > gnutls_free(*crl); > + *crl = NULL; This line shouldn't be necessary as `gnutls_free` is defined as a macro: `#define gnutls_free(a) gnutls_free((void *) (a)), a=NULL`. -- Daiki Ueno started a new discussion on lib/pkcs11_privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1136952437 > (*key)->uinfo = p11_kit_uri_new(); > if ((*key)->uinfo == NULL) { > free(*key); Not an issue in this MR, but this line should use `gnutls_free`. We probably should have an automated way to detect such mismatches. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 You're receiving 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 Oct 16 01:25:50 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 15 Oct 2022 23:25:50 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (#1415) In-Reply-To: References: Message-ID: Daiki Ueno commented: > I cannot send merge requests, the e-mail addresses generated by Gitlab are not in a format accepted by 'git send-email' I can open an MR for you, though I'm not sure how the email addresses are related to opening MR; are you using the email based [interface](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#by-sending-an-email)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1415#note_1136953306 You're receiving 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 Oct 16 03:14:17 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Oct 2022 01:14:17 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1136970650 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { Can we fix the issue without removing the logic using `cert_set`? The point of introducing `cert_set` was to keep the algorithm being $`O(n)`$, while this patch seems to make it $`O(n^2)`$ at the worst case, also assuming the original certificate chain is sorted. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1136970650 You're receiving 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 Oct 16 07:04:33 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Oct 2022 05:04:33 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1136984774 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { On 2022-10-16 Daiki Ueno wrote: > Can we fix the issue without removing the logic using `cert_set`? The point of introducing `cert_set` was to keep the algorithm being $`O(n)`$, while this patch seems to make it $`O(n^2)`$ at the worst case, also assuming the original certificate chain is sorted. This hinges on [verify-high.c line 1494](lib/x509/verify-high.c#L1494) ~~~c /* [...] Start with index 1, as the first element may be re-checked after issuer retrieval. */ ~~~ The current code explicitly avoids taking the first item (in the context of the bug report this is the server certificate, but can it be something else, too?) into account but I do not understand the rationale **at all**. Does the first item change "after issuer retrieval"? And if not why should not we not remove copies further down in the chain? (The algorithm keeps the first instance and removes later ones.) cu Andreas -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1136984774 You're receiving 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 Oct 17 01:14:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Oct 2022 23:14:43 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137184768 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { That's a good point. The only reason we start from `cert_list[i + 1]` is that, if issuer retrieval happens, `cert_list[i]` is already marked as seen in `cert_set` and reported as a duplicate. So I guess a fix would be something like: (1) do not skip the first element and (2) delay registering `cert_list[i]` after issuer retrieval. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137184768 You're receiving 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 Oct 17 01:56:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Oct 2022 23:56:28 +0000 Subject: [gnutls-devel] GnuTLS | Discussion: tarball signing practice (#1407) In-Reply-To: References: Message-ID: Sam James commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1407#note_1137196723 As long as the release is signed by someone in that keyring, of course, then it'd be fine with me (speaking for Gentoo). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1407#note_1137196723 You're receiving 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 Oct 17 02:28:05 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 00:28:05 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 was reviewed by Sam James -- Sam James commented on a discussion on lib/pkcs11_privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1137210016 > (*key)->uinfo = p11_kit_uri_new(); > if ((*key)->uinfo == NULL) { > free(*key); There's almost a way, but it doesn't seem to work for gnutls' setup: ``` ./../includes/gnutls/gnutls.h:2346:1: warning: 'malloc' attribute ignored; valid only for functions [-Wattributes] 2346 | extern _SYM_EXPORT gnutls_alloc_function gnutls_malloc; | ^~~~~~ ``` Rough diff without autotools wiring up for checking support in compiler: ``` diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index 9b700e03f..f47e6cac4 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -2341,10 +2341,13 @@ typedef void *(*gnutls_realloc_function) (void *, size_t); void gnutls_global_set_time_function(gnutls_time_func time_func); /* For use in callbacks */ +extern _SYM_EXPORT gnutls_free_function gnutls_free; +__attribute__ ((malloc (gnutls_free, 1))) extern _SYM_EXPORT gnutls_alloc_function gnutls_malloc; +__attribute__ ((malloc (gnutls_free, 1))) extern _SYM_EXPORT gnutls_realloc_function gnutls_realloc; +__attribute__ ((malloc (gnutls_free, 1))) extern _SYM_EXPORT gnutls_calloc_function gnutls_calloc; -extern _SYM_EXPORT gnutls_free_function gnutls_free; #ifdef GNUTLS_INTERNAL_BUILD #define gnutls_free(a) gnutls_free((void *) (a)), a=NULL ``` Take a look at: - https://developers.redhat.com/blog/2021/04/30/detecting-memory-management-bugs-with-gcc-11-part-1-understanding-dynamic-allocation#attribute_malloc (this is the main one) - https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11 - https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 You're receiving 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 Oct 17 02:29:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 00:29:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Sam James commented on a discussion on lib/pkcs11_privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1137210346 > (*key)->uinfo = p11_kit_uri_new(); > if ((*key)->uinfo == NULL) { > free(*key); I wonder how far one would get by just defining gnutls_malloc, giving it the malloc attribute (not the extended one I've used above, but the normal one), and calling normal malloc. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1137210346 You're receiving 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 Oct 17 02:31:19 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 00:31:19 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Sam James commented on a discussion on lib/pkcs11_privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1137210608 > (*key)->uinfo = p11_kit_uri_new(); > if ((*key)->uinfo == NULL) { > free(*key); Oh, sorry, I missed @ebblake's comments above where he mentioned this problem. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1137210608 You're receiving 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 Oct 17 07:38:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 05:38:14 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643#note_1137332686 Indeed; I've consolidated the push/pop macros to adopt that change. Could you take a second look? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643#note_1137332686 You're receiving 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 Oct 17 10:25:55 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 08:25:55 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137551938 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { [gnutls-duplicate-ee.patch](/uploads/b6f84e270f5ca9a93753f92d5b6e08a9/gnutls-duplicate-ee.patch) is an attempt for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137551938 You're receiving 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 Oct 17 11:14:13 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 09:14:13 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137647335 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { @dueno Your patch fixes the issue and the tests are passing. I would only suggest changing memmove for memcpy as I dont see a reason why the memories would overlap. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137647335 You're receiving 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 Oct 17 11:51:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 09:51:14 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643#note_1137714358 Looks good! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643#note_1137714358 You're receiving 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 Oct 17 11:51:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 09:51:14 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: All discussions on merge request !1643 were resolved by Alexander Sosedkin https://gitlab.com/gnutls/gnutls/-/merge_requests/1643 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643 You're receiving 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 Oct 17 11:53:19 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 09:53:19 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137720424 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { @ZoltanFridrich the code is: ```c memmove(set->node[hash].certs[i], set->node[hash].certs[i + 1], (set->node[hash].size - i - 1) * sizeof(cert)); ``` which is trying to remove the gap by moving the following memory areas by one entry ahead, so there is an overlap I think. But the code is a little sketchy; I guess we could better use a hash table provided by gnulib instead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137720424 You're receiving 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 Oct 17 12:14:20 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 10:14:20 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137773727 > - if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN)) { > - sorted_size = _gnutls_sort_clist(&cert_list[i], > - cert_list_size - i); > - } > - > - /* Remove duplicates. Start with index 1, as the first element > - * may be re-checked after issuer retrieval. */ > - for (j = 1; j < sorted_size; j++) { > - if (cert_set_contains(&cert_set, cert_list[i + j])) { > - if (i + j < cert_list_size - 1) { > - memmove(&cert_list[i + j], > - &cert_list[i + j + 1], > - sizeof(cert_list[i])); > + /* Remove duplicates */ > + for (i = 0; i < cert_list_size - 1 && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++i) { > + for (j = i + 1; j < cert_list_size && cert_list_size <= DEFAULT_MAX_VERIFY_DEPTH; ++j) { In your code there definitely is an overlap, but not in the original code where it only moves sizeof(cert). I can however rework this using gnulib data structures as you said. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1137773727 You're receiving 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 Oct 17 13:43:05 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 11:43:05 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Add basic tlsv1-2 test into .gitlab-ci and update tls-interoperability submodule commit (!1654) References: Message-ID: Peter Leitmann created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1654 Project:Branches: not4pedro/gnutls:tlsv1-2-tags to gnutls/gnutls:master Author: Peter Leitmann Add a description of the new feature/bug fix. Reference any relevant bugs. ## 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/1654 You're receiving 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 Oct 17 14:29:12 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 12:29:12 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) 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/1643#note_1138015815 You're receiving 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 Oct 17 14:29:19 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 12:29:19 +0000 Subject: [gnutls-devel] GnuTLS | fips: mark symmetric key crypto operations with short key and output sizes non-approved (!1643) In-Reply-To: References: Message-ID: Merge request !1643 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643 Project:Branches: dueno/gnutls:wip/dueno/symkey-limit to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1643 You're receiving 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 Oct 17 14:41:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 12:41:47 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: Following is the Kernel patch required for this feature: https://gitlab.com/FrantisekKrenzelok/kernel-ark/-/commit/b49e17b0aa497477bfe359dee75a1a9d82bc05d9 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1138039857 You're receiving 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 Oct 17 15:00:56 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 13:00:56 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented on a discussion on lib/x509/crl.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138076079 > if (result < 0) { > gnutls_assert(); > gnutls_free(*crl); > + *crl = NULL; Oh. I didn't spot that. If I read the header right, that is only the case when GNUTLS_INTERNAL_BUILD is defined; but that appears to be the case in all of the gnutls code base? So you are right that the code base is avoiding stale pointers in a lot more places than I thought on my first read through. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138076079 You're receiving 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 Oct 17 15:02:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 13:02:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented on a discussion on lib/pkcs11_privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138078435 > (*key)->uinfo = p11_kit_uri_new(); > if ((*key)->uinfo == NULL) { > free(*key); Yeah, attribute malloc (either the bare version meaning "returns an unaliased pointer" or the parameterized version meaning "the returned pointer must be passed to this dealloc function") doesn't work when _init functions aren't actually returning a pointer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138078435 You're receiving 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 Oct 17 15:07:31 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 13:07:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138088534 Of course, now that I've belatedly learned that gnutls_free() is a macro that calls the user's function then slams the pointer to NULL, my audit was wrong; I am less certain whether there are code paths that failed to set the pointer to NULL on all exit paths, and will need to redo the audit... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138088534 You're receiving 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 Oct 17 15:21:01 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 13:21:01 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: All discussions on merge request !1625 were resolved by Franti?ek Kren?elok https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 You're receiving 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 Oct 17 15:34:44 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 13:34:44 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: All discussions on merge request !1653 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 17 16:56:06 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Oct 2022 14:56:06 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: Series respun with fewer code changes (now that I know about the gnutls_free() macro), and with improved commit messages as well as documentation on gnutls_init(). I still did not try to adjust documentation on any of the other affected functions; should I? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138373675 You're receiving 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 Oct 18 05:42:46 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 03:42:46 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 Project:Branches: dueno/gnutls:wip/dek-info to gnutls/gnutls:master Author: Daiki Ueno Some tools, for example win-acme, create encrypted private keys in OpenSSL's traditional format containing lowercase hex digits in the IV part of the DEK-Info PEM header. These key files are accepted by OpenSSL. Prior to this patch, GnuTLS did reject these keys with GNUTLS_E_INVALID_REQUEST. Signed-off-by: Tim Kosse ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [ ] 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/1655 You're receiving 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 Oct 18 05:45:53 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 03:45:53 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/x509/privkey_openssl.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1139016211 > x = (*c) - '0'; > else if (*c >= 'A' && *c <= 'F') > x = (*c) - 'A' + 10; > + else if (*c >= 'a' && *c <= 'f') I suppose we could simply write `c_isxdigit(*c)`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1139016211 You're receiving 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 Oct 18 10:57:53 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 08:57:53 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: All discussions on merge request !1650 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 18 11:24:07 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 09:24:07 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Merge request !1650 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 18 11:24:20 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 09:24:20 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650#note_1139419985 You're receiving 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 Oct 18 11:37:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 09:37:43 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (#1415) In-Reply-To: References: Message-ID: Tim Kosse commented: > I can open an MR for you Thank you, I just saw you created it. > are you using the email based [interface](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#by-sending-an-email)? Yes, if I go to https://gitlab.com/gnutls/gnutls/-/merge_requests I don't see any other way to create a merge request, other than by writing an e-mail. However the email address that is given when I click the link on the bottom of the page has a local-part that is longer than the limit of 64 octets as defined in RFC 5321 section 4.5.3.1.1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1415#note_1139440440 You're receiving 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 Oct 18 12:07:51 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 10:07:51 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Merge request !1650 was scheduled to merge after pipeline succeeds by Zolt?n Fridrich Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 18 12:18:40 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 10:18:40 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (#1415) In-Reply-To: References: Message-ID: Daiki Ueno commented: > Yes, if I go to https://gitlab.com/gnutls/gnutls/-/merge_requests I don't see any other way to create a merge request, other than by writing an e-mail. I actually haven't used the email based interface. My usual workflow is: 1. fork this repository by clicking "Fork" button ([link](https://gitlab.com/gnutls/gnutls/-/forks/new)) 2. clone your fork (`git clone git at gitlab.com:/gnutls.git` I suppose) 3. make some changes and push it 4. click "+" and select "New merge request" ([link](https://gitlab.com/gnutls/gnutls/-/merge_requests/new)) 5. select your fork as the source branch and proceed with "Compare branches and continue" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1415#note_1139501031 You're receiving 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 Oct 18 14:30:17 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 12:30:17 +0000 Subject: [gnutls-devel] GnuTLS | Add a priority string modifier to disable sending status_request extension (#1378) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via merge request !1650 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1650) Issue #1378: https://gitlab.com/gnutls/gnutls/-/issues/1378 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1378 You're receiving 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 Oct 18 14:30:17 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 12:30:17 +0000 Subject: [gnutls-devel] GnuTLS | Add NO_STATUS_REQUEST priority string modifier (!1650) In-Reply-To: References: Message-ID: Merge request !1650 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1650 You're receiving 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 Oct 18 15:24:39 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 13:24:39 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Add basic tlsv1-2 test into .gitlab-ci and update tls-interoperability submodule commit (!1654) In-Reply-To: References: Message-ID: Merge request !1654 was closed by Peter Leitmann Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1654 Project:Branches: not4pedro/gnutls:tlsv1-2-tags to gnutls/gnutls:master Author: Peter Leitmann Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1654 You're receiving 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 Oct 18 15:26:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Oct 2022 13:26:25 +0000 Subject: [gnutls-devel] GnuTLS | Add basic tlsv1-2 test into .gitlab-ci and update tls-interoperability submodule commit (!1656) References: Message-ID: Peter Leitmann created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1656 Project:Branches: not4pedro/gnutls:tlsv1-2-tags to gnutls/gnutls:master Author: Peter Leitmann 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 * [x] 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/1656 You're receiving 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 Oct 19 11:25:39 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 09:25:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/random.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1141115051 > -/* This file handles all the internal functions that cope with random data. > - */ > +/* This file handles all the internal functions that cope with random data */ nit: the previous style was more aligned with the Linux kernel coding style: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting -- Daiki Ueno started a new discussion on lib/random.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1141115065 > +/* A global list of all allocated contexts. > + * A safety measure in case thread specific > + * context cannot be freed on thread exit */ nit: comment style -- Daiki Ueno started a new discussion on lib/random.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1141115069 > +static void delete_ctx(void *ctx) > +{ > + gnutls_static_mutex_lock(&gnutls_rnd_list_mutex); Good to check the return value (or explicitly ignore it with `(void)` cast). -- Daiki Ueno started a new discussion on bootstrap.conf: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1141115077 > common_modules=" > -alloca attribute byteswap c-ctype c-strcase explicit_bzero fopen-gnu func getline gettext-h gettimeofday hash hash-pjw-bare arpa_inet inet_ntop inet_pton intprops lock memmem-simple minmax netdb netinet_in read-file secure_getenv setsockopt snprintf stdint stpcpy strcase strdup-posix strndup strtok_r strverscmp sys_socket sys_stat sys_types threadlib time_r unistd valgrind-tests vasprintf verify vsnprintf xalloc-oversized > +alloca attribute byteswap c-ctype c-strcase explicit_bzero fopen-gnu func getline gettext-h gettimeofday hash hash-pjw-bare arpa_inet inet_ntop inet_pton intprops linkedhash-list list lock memmem-simple minmax netdb netinet_in read-file secure_getenv setsockopt snprintf stdint stpcpy strcase strdup-posix strndup strtok_r strverscmp sys_socket sys_stat sys_types threadlib time_r tls unistd valgrind-tests vasprintf verify vsnprintf xalloc-oversized `linkedhash-list` depends on `list`, so I suppose it's automatically pulled in? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 You're receiving 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 Oct 19 11:25:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 09:25:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647#note_1141115139 You're receiving 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 Oct 19 11:25:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 09:25:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: Merge request !1647 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 You're receiving 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 Oct 19 14:15:26 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 12:15:26 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: All discussions on merge request !1647 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 You're receiving 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 Oct 19 14:15:31 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 12:15:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: Merge request !1647 was scheduled to merge after pipeline succeeds by Zolt?n Fridrich Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 You're receiving 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 Oct 19 17:12:18 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 15:12:18 +0000 Subject: [gnutls-devel] GnuTLS | bug in gnutls_init() (#1414) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: I believe that if a function outputs its result via an argument, the argument should be left untouched in case of an error. Currently this is clearly not the case with `gnutls_init` which sets session to `NULL` in some cases (but not all) when error occurs. However, I think that handling an error as follows is generally an incorrect approach. ``` ret = gnutls_init(session, flags); if (ret < 0) gnutls_deinit(session); return ret; ``` User should not expect to clean up functions output if that function failed. If this results in segfault, than its the users fault (unless the scenario was documented and the function is bugged). I would suggest either that - `gnutls_init` will not modify the output argument on error. or - `gnutls_init` will always set the output argument to some defined value on error. (in this case `NULL`) In either case, the documentation of `gnutls_init` should be updated to clearly state what happens with session when error occurs. I would prefer to not touch the argument on error but both solutions are ok imo. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1414#note_1141774040 You're receiving 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 Oct 19 18:06:37 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 16:06:37 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_rnd_init allocates memory per thread but does not seem to deallocate it (#1401) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via merge request !1647 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1647) Issue #1401: https://gitlab.com/gnutls/gnutls/-/issues/1401 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1401 You're receiving 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 Oct 19 18:06:37 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Oct 2022 16:06:37 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_rnd manage memory per-thread (!1647) In-Reply-To: References: Message-ID: Merge request !1647 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1647 You're receiving 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 Oct 20 11:05:26 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 09:05:26 +0000 Subject: [gnutls-devel] GnuTLS | Segfault during handshake on server connection if no private key is supplied (#1412) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.0 (Oct 1, 2022?Nov 15, 2022) ( https://gitlab.com/gnutls/gnutls/-/milestones/30 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1412 You're receiving 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 Oct 20 11:05:24 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 09:05:24 +0000 Subject: [gnutls-devel] GnuTLS | Segfault during handshake on server connection if no private key is supplied (#1412) In-Reply-To: References: Message-ID: Reassigned Issue 1412 https://gitlab.com/gnutls/gnutls/-/issues/1412 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1412 You're receiving 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 Oct 20 12:40:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 10:40:25 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Reassigned merge request 1657 https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 You're receiving 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 Oct 20 12:40:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 10:40:25 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) 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/1657 You're receiving 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 Oct 20 12:40:26 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 10:40:26 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) References: Message-ID: Zolt?n Fridrich created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno Closes #1412 ## 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/1657 You're receiving 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 Oct 20 12:41:35 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 10:41:35 +0000 Subject: [gnutls-devel] GnuTLS | Segfault during handshake on server connection if no private key is supplied (#1412) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: Thank you for the reproducer. It greatly helped. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1412#note_1142865617 You're receiving 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 Oct 20 12:45:35 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 10:45:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: I have put the check into the function where the segfault stems. A bit disappointing is that the functions return value serves as a boolean rather than error code. With this change the reproducer no longer ends in a segfault, but the connection fails with following error: `*** Handshake has failed (No supported cipher suites have been found.)` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1142873616 You're receiving 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 Oct 20 15:36:22 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 13:36:22 +0000 Subject: [gnutls-devel] GnuTLS | bug in gnutls_init() (#1414) In-Reply-To: References: Message-ID: GitLab Support Bot commented: > New response for issue #1414: > > Author: Zolt?n Fridrich > > I believe that if a function outputs its result via an argument, the argument should be left untouched in case of an error. Currently this is clearly not the case with `gnutls_init` which sets session to `NULL` in some cases (but not all) when error occurs. However, I think that handling an error as follows is generally an incorrect approach. But after auditing the code base, over 80% of the gnutls*_init() functions DO set the parameter to NULL on most or all of the error cases; only a very limited few were extremely careful to never touch the parameter on failure (gnutls_x509_crt_init being a prime example). > ``` > ret = gnutls_init(session, flags); > if (ret < 0) > gnutls_deinit(session); > return ret; > ``` > User should not expect to clean up functions output if that function failed. If this results in segfault, than its the users fault (unless the scenario was documented and the function is bugged). It is undocumented what the users should do. Some avoid calling the _deinit on errors, but others do not. Unless you document it, the segfault from freeing uninit memory is not the user's fault, but a bug in gnutls' documentation. But even if you document that the memory remains uninit on failure, you have NOT actually uniformly implemented that, and there is EXISTING code in the wild that DOES call the _deinit function, and therefore WILL crash. > > I would suggest either that > - `gnutls_init` will not modify the output argument on error. Doable, but a LOT more churn (as I said, I already did the audit, and more than 80% of the *_init functions would need changing). > or > - `gnutls_init` will always set the output argument to some defined value on error. (in this case `NULL`) That was my preference as well; see https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 > In either case, the documentation of `gnutls_init` should be updated to clearly state what happens with session when error occurs. My preference as well, also in the merge commit (well, for gnutls_init(); but if desired, I could expend the documentation efforts to repeat that information for all *_init functions). > > I would prefer to not touch the argument on error but both solutions are ok imo. I hope my merge commit can persuade you to ALWAYS touch the argument on all exit paths, while at the same time documenting that the usesr need not call the _deinit function on failure, and furthermore that the user MAY (but not MUST) pre-zero the memory before calling _init, such that even if the call _deinit on failure, it is safe in (almost) all cases. The lone exception is gnutls_pkcs11_privkey_init(), where the use of the wrong free() function causes certain failures to cause a double-free if the user calls _deinit on certain failures. Blindly claiming that it is the user's fault for segfaulting on deinit after failure when gnutls documentation did not make a strong guarantee on what the user should do is not a very nice attitude for security-sensitive software to be portraying.
... On Wed, Oct 19, 2022 at 03:12:18PM +0000, Zolt?n Fridrich (@ZoltanFridrich) wrote: -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
-- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1414#note_1143168550 You're receiving 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 Oct 20 16:43:29 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 14:43:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: Rebased the patches, tweaked some documentation wording, added a paragraph to the manual, and fixed for consistent use of TAB. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1143329678 You're receiving 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 Oct 20 16:44:45 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 14:44:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: All discussions on merge request !1652 were resolved by Eric Blake https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652 You're receiving 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 Oct 20 16:48:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 14:48:25 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: Always initialize *session (!1652) In-Reply-To: References: Message-ID: Eric Blake commented: Rebase to consistently use 3.8.0 as the next version number, based on recent NEWS change -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1143340889 You're receiving 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 Oct 20 17:17:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 15:17:49 +0000 Subject: [gnutls-devel] GnuTLS | Unknown certificate compression algorithm leads to an illegal_parameter alert (#1416) References: Message-ID: Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1416 Advertizing a certificate compression not known to gnutls in CompressCertificateExtension leads to `illegal_parameter` instead of ignoring the extension and proceeding with no compression. Code pointer: https://gitlab.com/gnutls/gnutls/-/blob/b69cbc76e46bbface6f92a0485a6c7ae646c6d6b/lib/ext/compress_certificate.c#L197 (Found using tlsfuzzer, though the [corresponding](https://github.com/tlsfuzzer/tlsfuzzer/pull/802) [code](https://github.com/tlsfuzzer/tlslite-ng/pull/484) isn't mainlined yet.) CC @ZoltanFridrich. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1416 You're receiving 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 Oct 21 01:11:41 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 20 Oct 2022 23:11:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/privkey.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1143910158 > { > const gnutls_sign_entry_st *se; > > + if (privkey == NULL) nit: I'd suggest `unlikely(privkey == NULL)` as it is an unusual occasion -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1143910158 You're receiving 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 Oct 21 06:43:23 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 04:43:23 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Daiki Ueno commented: Although this certainly would fix the original issue, I'm not sure if `_gnutls_privkey_compatible_with_sig` is the best place to add the check. As the server must have a private key when certificate authentication is used, IMO a more appropriate place would be somewhere in `lib/auth/cert.c` (e.g., `_gnutls_select_server_cert` or `call_get_cert_callback`, where `session->internals.selected_key` is looked up but not found). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1144068451 You're receiving 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 Oct 21 09:19:48 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 07:19:48 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 Project:Branches: dueno/gnutls:wip/dueno/ccm-tlen to gnutls/gnutls:master Author: Daiki Ueno This changes the following checks in CCM used under FIPS mode: - any use of tag length other than 4, 6, 8, 10, 12, 14, and 16 returns error - use of tag length either 4 or 6 causes the service indicator to transition to not-approved state ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] 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/1658 You're receiving 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 Oct 21 09:25:08 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 07:25:08 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1144177126 Alright, but I think the check should stay in `_gnutls_privkey_compatible_with_sig` aswell as it would otherwise try to dereference `NULL`. I will just add another one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1144177126 You're receiving 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 Oct 21 11:02:34 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:02:34 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: All discussions on merge request !1657 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 You're receiving 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 Oct 21 11:16:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:16:10 +0000 Subject: [gnutls-devel] GnuTLS | build: fix AUTHORS generation (!1659) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1659 Project:Branches: dueno/gnutls:wip/dueno/git-authors to gnutls/gnutls:master Author: Daiki Ueno Without revision supplied, git shortlog expects to read commits from stdin and produces the following error: ```console GEN AUTHORS fatal: using multiple --group options with stdin is not supported ``` Fixes: #1409 ## 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/1659 You're receiving 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 Oct 21 11:23:08 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:23:08 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Reassigned merge request 1660 https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 Assignee changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 21 11:23:08 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:23:08 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Reviewer changed to Daiki Ueno and Alexander Sosedkin -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 21 11:23:10 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:23:10 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) References: Message-ID: Zolt?n Fridrich created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewers: Daiki Ueno and Alexander Sosedkin Closes #1416 ## 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/1660 You're receiving 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 Oct 21 11:27:52 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:27:52 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/ext/compress_certificate.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144359691 > num = _gnutls_read_uint16(data + i + i + 1); > methods[i] = _gnutls_compress_certificate_num2method(num); > - if (methods[i] == GNUTLS_COMP_UNKNOWN) This check is legitimate: we should reject any unknown codepoint for a compression algorithm. -- Daiki Ueno started a new discussion on lib/ext/compress_certificate.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144359696 > method = methods[i]; > goto endloop; > } The fallthrough logic should probably be here instead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 21 11:32:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:32:49 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/ext/compress_certificate.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144367982 > for (i = 0; i < methods_len; ++i) { > num = _gnutls_read_uint16(data + i + i + 1); > methods[i] = _gnutls_compress_certificate_num2method(num); > - if (methods[i] == GNUTLS_COMP_UNKNOWN) But that is literally the point of #1416 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144367982 You're receiving 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 Oct 21 11:32:51 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 09:32:51 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/ext/compress_certificate.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144368034 > if (methods[i] == priv->methods[j]) { > method = methods[i]; > goto endloop; > } Why? I don't get it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144368034 You're receiving 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 Oct 21 12:46:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 10:46:14 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 was reviewed by Clemens Lang -- Clemens Lang started a new discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1144471589 > + */ > + switch (tag_size) { > + case 4: case 6: My understanding was that technically values of 4 and 6 are also FIPS-approved, just special care should be taken when using them. I don't think we should switch the indicator for those values. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 You're receiving 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 Oct 21 12:49:13 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 10:49:13 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/compress_certificate.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144474904 > for (i = 0; i < methods_len; ++i) { > num = _gnutls_read_uint16(data + i + i + 1); > methods[i] = _gnutls_compress_certificate_num2method(num); > - if (methods[i] == GNUTLS_COMP_UNKNOWN) Oh, yeah; I now agree with that. In that case I would suggest skipping unknown methods rather than storing it, something like: ```c size_t k; for (i = 0, k = 0; i < methods_len; ++i) { num = gnutls_read_uint16(data + i + i + 1); method = _gnutls_compress_certificate_num2method(num); if (method == GNUTLS_COMP_UNKNOWN) continue; methods[k++] = method; } for (i = 0; i < k; i++) { ... } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144474904 You're receiving 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 Oct 21 14:24:37 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 12:24:37 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1144606023 > + break; > + default: > + if (_gnutls_fips_mode_enabled()) { Would it hurt to also flip the indicator to `ERROR`? -- Alexander Sosedkin started a new discussion on tests/fips-test.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1144606032 > + fips_pop_context(fips_context, expected_state); > + > + /* We can't proceed with decryption when encryption failed, ... leaving us with decryption limitations untested in <4 tag length case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 You're receiving 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 Oct 21 15:54:29 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 13:54:29 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: e02ffe33 - tested to proceed without compression when client sends algorithm = 0, 16383, 16384, 16385, 65534 or 65535. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1144737549 You're receiving 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 Oct 21 18:03:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 16:03:25 +0000 Subject: [gnutls-devel] GnuTLS | build: fix AUTHORS generation (!1659) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Tested on Fedora 35. Error no longer appears, a list of 205 authors is generated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1659#note_1144915978 You're receiving 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 Oct 21 18:03:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 16:03:28 +0000 Subject: [gnutls-devel] GnuTLS | build: fix AUTHORS generation (!1659) In-Reply-To: References: Message-ID: Merge request !1659 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1659 Project:Branches: dueno/gnutls:wip/dueno/git-authors 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/1659 You're receiving 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 Oct 21 21:45:19 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 19:45:19 +0000 Subject: [gnutls-devel] GnuTLS | KTLS key update support (!1625) In-Reply-To: References: Message-ID: toidiu commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1145092003 > KTLS will be used until key_update is received or send, after that it will be disabled and GnuTLS will fallback to default i.e. gnutls will handle encryption and decryption Is there a test that confirms this behavior. I see that `session->internals.ktls_enabled = 0;` is set but the socket is still ktls enabled and has the previous encryption keys so from what I can tell there will be double encryption. ``` ktls-enabled plaintext -> ktls -> ciphertext ktls-disabled plaintext -> gnutls_encrypt -> ktls -> garbage ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1145092003 You're receiving 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 Oct 22 00:40:55 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 22:40:55 +0000 Subject: [gnutls-devel] GnuTLS | build: fix AUTHORS generation (!1659) In-Reply-To: References: Message-ID: Merge request !1659 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1659 Project:Branches: dueno/gnutls:wip/dueno/git-authors to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1659 You're receiving 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 Oct 22 00:40:55 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Oct 2022 22:40:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball has almost empty AUTHORS file (#1409) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno via merge request !1659 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1659) Issue #1409: https://gitlab.com/gnutls/gnutls/-/issues/1409 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1409 You're receiving 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 Oct 22 02:25:15 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 00:25:15 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211602 > if (unlikely(encr_size < plain_size + tag_size)) > return gnutls_assert_val(GNUTLS_E_SHORT_MEMORY_BUFFER); > > + /* SP800-38C A.1 says Tlen must be a multiple of 16 between 32 > + * and 128, while B.2 says Tlen smaller than 64 should not be > + * used under sufficient restriction. > + */ > + switch (tag_size) { > + case 4: case 6: OK, I've made a change to not touch the service indicator for them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211602 You're receiving 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 Oct 22 02:25:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 00:25:43 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211674 > if (unlikely(encr_size < plain_size + tag_size)) > return gnutls_assert_val(GNUTLS_E_SHORT_MEMORY_BUFFER); > > + /* SP800-38C A.1 says Tlen must be a multiple of 16 between 32 > + * and 128, while B.2 says Tlen smaller than 64 should not be > + * used under sufficient restriction. > + */ > + switch (tag_size) { > + case 4: case 6: > + _gnutls_switch_fips_state(GNUTLS_FIPS140_OP_NOT_APPROVED); > + FALLTHROUGH; > + case 8: case 10: case 12: case 14: case 16: > + break; > + default: > + if (_gnutls_fips_mode_enabled()) { Good point; added the transition. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211674 You're receiving 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 Oct 22 02:26:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 00:26:16 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/fips-test.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211750 > + > + fips_push_context(fips_context); > + memset(buffer, 0, sizeof(buffer)); > + length = sizeof(buffer); > + ret = gnutls_aead_cipher_encrypt(h, iv_data, gnutls_cipher_get_iv_size(cipher), > + NULL, 0, tag_length, > + buffer, length - tag_length, > + buffer, &length); > + if (ret != expected_ret) { > + fail("gnutls_aead_cipher_encrypt(%s) returned %d while %d is expected\n", > + gnutls_cipher_get_name(cipher), > + ret, expected_ret); > + } > + fips_pop_context(fips_context, expected_state); > + > + /* We can't proceed with decryption when encryption failed, Reworked so the decryption test is always exercised. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1145211750 You're receiving 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 Oct 22 02:26:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 00:26:16 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: All discussions on merge request !1658 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 You're receiving 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 Oct 22 10:30:51 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 08:30:51 +0000 Subject: [gnutls-devel] GnuTLS | Handle post-handshake messages when KTLS is enabled (#1299) In-Reply-To: References: Message-ID: Daiki Ueno commented: @FrantisekKrenzelok can we close this as it has been fixed as part of !1625? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1299#note_1145292861 You're receiving 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 Oct 22 10:33:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 22 Oct 2022 08:33:25 +0000 Subject: [gnutls-devel] GnuTLS | Support KTLS in FreeBSD (#1417) References: Message-ID: Daiki Ueno created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1417 The FreeBSD kernel provides a slightly different flavor of KTLS support than Linux. It would be nice to detect/enable it transparently. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1417 You're receiving 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 Oct 23 13:30:56 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 23 Oct 2022 11:30:56 +0000 Subject: [gnutls-devel] GnuTLS | Discussion: tarball signing practice (#1407) In-Reply-To: References: Message-ID: Andreas Metzler commented: We had a little but of discussion in Debian about this on https://bugs.debian.org/1010955 since our (Debian's) tooling is not up to this yet, we currently check whether *all* signatures are trusted instead of *any*. I think Daniel Kahn Gillmor summed up nicely why this is wrong: > [...] Requiring every discovered signature to be valid is a mistake. For example, it means that projects that start publishing an OpenPGP v5 signature (when rfc4880bis is finally released) alongside their OpenPGP v4 signatures will fail to be validated. > [...] > If anything, the correct move here is to have uscan be satisfied as long as it finds *any* valid signature from any key in the keyring located in debian/upstream/signing-key.asc. > > Here's another way of looking at it: consider a malicious network adversary capable of interposing themselves and tampering with either the tarball or the signature -- it is trivial (and unavoidable) that the adversary can make a good signature fail; just fiddle some bits in the signature or the tarball. What we critically want to avoid is for them to be able to make a bad signature appear good. > > But note that if we believe every supplied signature must be good when a multiple signature is supplied, and one signature is from an unknown party, then a network attacker can simply *remove* the unknown signature, and the remaining signatures will all pass, converting a "bad" multi-sig into a "good" single-sig. The threat model for this approach is clearly muddled! > > By permitting a single signature from any signer to validate, we are not increasing the capabilities of the attacker at all. we're simply making the system more robust, and enabling upstream developers to smoothly migrate to new keys by signing with both keys for a period of time. Extrapolating from this I also think that GnuTLS should continue to have a limited set of *trusted* signers (= the published keyring) with every release being signed with one of these. There might be a bigger set of people preparing releases who might also sign, but they should not be added to trusted keyring just to fullfill a wrong technical requirement (every signature trusted). cu Andreas -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1407#note_1145518090 You're receiving 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 Oct 24 10:36:19 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 08:36:19 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: All discussions on merge request !1660 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 24 12:50:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 10:50:28 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1146207567 > if (unlikely(encr_size < plain_size + tag_size)) > return gnutls_assert_val(GNUTLS_E_SHORT_MEMORY_BUFFER); > > + /* SP800-38C A.1 says Tlen must be a multiple of 16 between 32 > + * and 128, while B.2 says Tlen smaller than 64 should not be > + * used under sufficient restriction. > + */ > + switch (tag_size) { > + case 4: case 6: I'm confused now. Is asymmetry of approvedness (as of 1747e92b) between encryption and decryption intentional? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1146207567 You're receiving 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 Oct 24 17:20:06 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 15:20:06 +0000 Subject: [gnutls-devel] GnuTLS | Handle post-handshake messages when KTLS is enabled (#1299) In-Reply-To: References: Message-ID: Issue was closed by Franti?ek Kren?elok Issue #1299: https://gitlab.com/gnutls/gnutls/-/issues/1299 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1299 You're receiving 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 Oct 24 22:54:18 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 20:54:18 +0000 Subject: [gnutls-devel] GnuTLS | Handle post-handshake messages when KTLS is enabled (#1299) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.0 (Oct 1, 2022?Nov 15, 2022) ( https://gitlab.com/gnutls/gnutls/-/milestones/30 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1299 You're receiving 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 Oct 24 22:54:26 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 20:54:26 +0000 Subject: [gnutls-devel] GnuTLS | Handle post-handshake messages when KTLS is enabled (#1299) In-Reply-To: References: Message-ID: Reassigned Issue 1299 https://gitlab.com/gnutls/gnutls/-/issues/1299 Assignee changed to Franti?ek Kren?elok -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1299 You're receiving 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 Oct 24 22:54:54 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 20:54:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.7.8 tarball has almost empty AUTHORS file (#1409) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.0 (Oct 1, 2022?Nov 15, 2022) ( https://gitlab.com/gnutls/gnutls/-/milestones/30 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1409 You're receiving 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 Oct 25 00:08:31 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 22:08:31 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: All discussions on merge request !1658 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 You're receiving 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 Oct 25 00:08:34 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 22:08:34 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/accelerated/aarch64/aes-ccm-aarch64.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1147011706 > if (unlikely(encr_size < plain_size + tag_size)) > return gnutls_assert_val(GNUTLS_E_SHORT_MEMORY_BUFFER); > > + /* SP800-38C A.1 says Tlen must be a multiple of 16 between 32 > + * and 128, while B.2 says Tlen smaller than 64 should not be > + * used under sufficient restriction. > + */ > + switch (tag_size) { > + case 4: case 6: No, it's just an oversight; thanks for spotting this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658#note_1147011706 You're receiving 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 Oct 25 01:40:58 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 23:40:58 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Merge request !1660 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewers: Daiki Ueno and Alexander Sosedkin -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 25 01:41:25 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Oct 2022 23:41:25 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Daiki Ueno commented: Should we modify the test to cover the scenario? Otherwise it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1147078593 You're receiving 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 Oct 25 06:42:06 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:42:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Merge request !1657 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 You're receiving 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 Oct 25 06:42:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:42:38 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me. Maybe we could include the provided reproducer as a test? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1147250034 You're receiving 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 Oct 25 06:52:39 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:52:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me. Can we include the reproducer as a test case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1147254663 You're receiving 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 Oct 25 06:52:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:52:38 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Merge request !1653 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel3 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 25 06:52:39 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:52:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/x509/verify-high.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1147254660 > - ret = cert_set_add(&cert_set, cert_list[i]); > - if (ret < 0) { > + if (gl_list_nx_add_last(records, cert_list[i]) == NULL) { nit: a little inconsistency with the above line: `if (gl_list_search(records, cert_list[i + j]))` written without explicit NULL check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 25 06:54:22 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 04:54:22 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Reviewer changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 You're receiving 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 Oct 25 07:15:03 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 05:15:03 +0000 Subject: [gnutls-devel] GnuTLS | bug in gnutls_init() (#1414) In-Reply-To: References: Message-ID: Daiki Ueno commented: For applications that target newer C compiler and thus do not care much about portability, I would suggest always NULL initializing those `gnutls_*_t` so it works nicely with `__attribute__((cleanup(...)))` as in: https://gitlab.com/dueno/quic-echo/-/blob/f21fed36f35efc3c8b3665bfbc9dbfc1482edb81/gnutls-glue.c#L268 That said, the proposed MR seems like a nice tightening. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1414#note_1147263859 You're receiving 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 Oct 25 09:14:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 07:14:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1147355407 I can add a test, sure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653#note_1147355407 You're receiving 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 Oct 25 09:15:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 07:15:14 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1147356430 Do we really want to? This is such a corner case and it is expected to fail anyway. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657#note_1147356430 You're receiving 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 Oct 25 10:35:05 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 08:35:05 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Merge request !1658 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 Project:Branches: dueno/gnutls:wip/dueno/ccm-tlen 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/1658 You're receiving 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 Oct 25 12:07:05 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 10:07:05 +0000 Subject: [gnutls-devel] GnuTLS | cipher: add restriction on CCM tag length under FIPS mode (!1658) In-Reply-To: References: Message-ID: Merge request !1658 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 Project:Branches: dueno/gnutls:wip/dueno/ccm-tlen to gnutls/gnutls:master Author: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1658 You're receiving 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 Oct 25 12:32:58 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 10:32:58 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1147699710 This might be a problem as I cant just set unknown methods via API. Other option would be to manually set extensions private data, but that fails: ``` ../lib/gnutls_int.h:56:10: fatal error: attribute.h: No such file or directory 56 | #include "attribute.h" | ^~~~~~~~~~~~~ ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1147699710 You're receiving 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 Oct 25 15:57:34 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 13:57:34 +0000 Subject: [gnutls-devel] GnuTLS | bug in gnutls_init() (#1414) In-Reply-To: References: Message-ID: GitLab Support Bot commented: > New response for issue #1414: > > Author: Daiki Ueno > > For applications that target newer C compiler and thus do not care much about portability, I would suggest always NULL initializing those `gnutls_*_t` so it works nicely with `__attribute__((cleanup(...)))` as in: > https://gitlab.com/dueno/quic-echo/-/blob/f21fed36f35efc3c8b3665bfbc9dbfc1482edb81/gnutls-glue.c#L268 Huh, that used 'gnutls_session_t session = NULL;', and the compiler was happy with it. Re-reading gnutls.h, I see that most of our gnutls_*_t types are typedefs either for enums (no corresponding *_init function) or as pointers to opaque struct types, as in: struct gnutls_session_int; typedef struct gnutls_session_int *gnutls_session_t; and not completely opaque types, where it would have been written: typedef gnutls_session_t; > > That said, the proposed MR seems like a nice tightening. In the MR, I documented zero initialization by calloc() or memset(); but if you are happy guaranteeing that 'gnutls_*_t obj = NULL' is going to remain a valid compile-time initialization (that is, we can no longer change the typedefs to be anything other than a pointer to a type), that's an easy tweak or followup to the MR as currently posted.
... On Tue, Oct 25, 2022 at 05:15:03AM +0000, Daiki Ueno (@dueno) wrote: -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
-- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1414#note_1148054059 You're receiving 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 Oct 25 16:58:54 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Oct 2022 14:58:54 +0000 Subject: [gnutls-devel] GnuTLS | Update libtasn1 to 4.19.0. (!1661) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661 Project:Branches: jas/gnutls:jas/update-libtasn1 to gnutls/gnutls:master Author: Simon Josefsson 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/1661 You're receiving 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 Oct 26 04:43:37 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 02:43:37 +0000 Subject: [gnutls-devel] GnuTLS | Update libtasn1 to 4.19.0. (!1661) In-Reply-To: References: Message-ID: Merge request !1661 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661 Project:Branches: jas/gnutls:jas/update-libtasn1 to gnutls/gnutls:master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661 You're receiving 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 Oct 26 04:44:07 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 02:44:07 +0000 Subject: [gnutls-devel] GnuTLS | Update libtasn1 to 4.19.0. (!1661) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661#note_1148791187 You're receiving 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 Oct 26 04:44:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 02:44:14 +0000 Subject: [gnutls-devel] GnuTLS | Update libtasn1 to 4.19.0. (!1661) In-Reply-To: References: Message-ID: Merge request !1661 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661 Project:Branches: jas/gnutls:jas/update-libtasn1 to gnutls/gnutls:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1661 You're receiving 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 Oct 26 05:56:11 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 03:56:11 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1148819893 If it is too hard, we could go without tests and update tlsfuzzer submodule once the [test case](https://github.com/tlsfuzzer/tlsfuzzer/pull/802) has been merged; in that case maybe good to create an issue to track that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1148819893 You're receiving 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 Oct 26 06:01:02 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 04:01:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutlsxx: become header-only library (!1622) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1148821579 As we are now planning towards 3.8 release, maybe we can go ahead and merge this? @createyourpersonalaccount would you mind rebasing it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1148821579 You're receiving 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 Oct 26 07:22:58 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 05:22:58 +0000 Subject: [gnutls-devel] GnuTLS | includes: define cleanup functions for the use with __attribute__((cleanup)) (!1662) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1662 Project:Branches: dueno/gnutls:wip/dueno/pointer-cleanup to gnutls/gnutls:master Author: Daiki Ueno This introduces `GNUTLS_DEFINE_POINTER_CLEANUP_FUNC` macro and definine wrapper functions around `gnutls_*_deinit`, to be used with the cleanup attribute supported by modern C compilers. That enables automatic cleanup of resources inside a function; applications could initialize pointers like the following: ```c __attribute__((cleanup(gnutls_deinitp))) gnutls_session_t session = NULL; if (err) return err; ``` Then `gnutls_deinit` is automatically called on session when the function returns error. ## 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/1662 You're receiving 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 Oct 26 09:29:13 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:29:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutlsxx: become header-only library (!1622) In-Reply-To: References: Message-ID: Nikolaos Chatzikonstantinou commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1148998496 @dueno I can do this. The patch is not yet complete; how to solve ? In summary, the header API is featureful while the underlying C library may be not due to `--without-PACKAGE` options specified in the configure step. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1148998496 You're receiving 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 Oct 26 09:51:23 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:51:23 +0000 Subject: [gnutls-devel] GnuTLS | Update tlsfuzzer submodule once tests for compress_certificate is ready (#1418) References: Message-ID: Zolt?n Fridrich created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1418 This is a reminder to update tlsfuzzer submodule once https://github.com/tlsfuzzer/tlsfuzzer/pull/802 has been merged so that we have more thorough tests for compress_certificate extension. Related #1416 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1418 You're receiving 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 Oct 26 09:53:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:53:00 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1149028065 Created #1418 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660#note_1149028065 You're receiving 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 Oct 26 09:53:02 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:53:02 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: All discussions on merge request !1660 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 26 09:53:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:53:28 +0000 Subject: [gnutls-devel] GnuTLS | Ignore unknown algorithms received in compress_certificate extension (!1660) In-Reply-To: References: Message-ID: Merge request !1660 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel2 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewers: Daiki Ueno and Alexander Sosedkin -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1660 You're receiving 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 Oct 26 09:53:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 07:53:28 +0000 Subject: [gnutls-devel] GnuTLS | Unknown certificate compression algorithm leads to an illegal_parameter alert (#1416) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via merge request !1660 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1660) Issue #1416: https://gitlab.com/gnutls/gnutls/-/issues/1416 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1416 You're receiving 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 Oct 26 12:06:15 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 10:06:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: All discussions on merge request !1657 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 You're receiving 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 Oct 26 12:06:30 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 10:06:30 +0000 Subject: [gnutls-devel] GnuTLS | Fix handshake segfault if no privkey is supplied (!1657) In-Reply-To: References: Message-ID: Merge request !1657 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1657 You're receiving 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 Oct 26 12:06:30 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 10:06:30 +0000 Subject: [gnutls-devel] GnuTLS | Segfault during handshake on server connection if no private key is supplied (#1412) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via merge request !1657 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1657) Issue #1412: https://gitlab.com/gnutls/gnutls/-/issues/1412 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1412 You're receiving 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 Oct 26 14:06:38 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 12:06:38 +0000 Subject: [gnutls-devel] GnuTLS | includes: define cleanup functions for the use with __attribute__((cleanup)) (!1662) In-Reply-To: References: Message-ID: Simon Josefsson commented: Interesting. How do a 'static inline' function declared in a public header file interact with API and ABI versioning? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1662#note_1149430492 You're receiving 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 Oct 26 14:28:20 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Oct 2022 12:28:20 +0000 Subject: [gnutls-devel] GnuTLS | Indent code? (#1419) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1419 GnuTLS code is generally indented well, but this is not enforced and there is a lot of newly added code that is indented differently. Having a consistent indentation style helps readability and thus maintainability, in my opinion. Gnulib's maint.mk has rules for both running 'indent' (make indent) and for checking that code is indented (make syntax-check). What do you think about indenting the code, and enabling 'make syntax-check' to check for this? Preferably shortly after the 3.8.0 release, I would suggest. I can prepare a merge request for this, but only if there is agreement that this is a good idea, and also decision on timing when to do it because it affects a lot of files and it will cause conflicts with other merge requests. The CONTRIBUTING file says to use 'indent -linux', so I suppose this is the style we should mandate? I prefer regular GNU-style indent though, but would not want to suggest changing anything in this area now. GnuTLS would have to update to modern gnulib first, though, but this is covered by (stale?) MR !1509. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1419 You're receiving 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 Oct 27 03:15:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 01:15:43 +0000 Subject: [gnutls-devel] GnuTLS | ktls fallback to userspace (#1420) References: Message-ID: toidiu created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1420 This was originally added as a comment: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625#note_1145092003 Looking at the ktls support for `key_update` code and the feature claims that it supports fallback to userspace TLS if a key_update is received (and kernel patch is not applied). However, having done local testing with ktls in other TLS libraries, I dont think its possible to fallback to userspace and undo the TCP_ULP once it has been enabled and crypto_info has been set. The current code is setting [`session->internals.ktls_enabled = 0;`](https://gitlab.com/gnutls/gnutls/-/blob/master/lib/tls13/key_update.c#L43) but the socket is still ktls enabled and has the previous encryption keys so from what I can tell there will be double encryption == garbage being sent on the wire. ``` ktls-enabled plaintext -> ktls -> ciphertext ktls-disabled plaintext -> gnutls_encrypt -> ktls -> garbage ``` I might also be a good idea to add a test for the fallback scenario to verify behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1420 You're receiving 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 Oct 27 09:25:32 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 07:25:32 +0000 Subject: [gnutls-devel] GnuTLS | gnutlsxx: become header-only library (!1622) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1150649354 Perhaps we could simply remove `#ifdef FEATURE` in `gnutlsxx.h`, and modify the C library to provide a stub? For example, I see: ```c++ void session::send_openpgp_cert (gnutls_openpgp_crt_status_t status) { #ifdef ENABLE_OPENPGP gnutls_openpgp_send_cert (s, status); #endif } ``` The `#ifdef ENABLE_OPENPGP` is actually unnecessary, because the C library always provides a stub `gnutls_openpgp_send_cert` definition for ABI compatibility reasons. However: ```c++ const char *server_session::get_srp_username () const { #ifdef ENABLE_SRP return gnutls_srp_server_get_username (s); #else return NULL; #endif } ``` This wouldn't compile if we remove `#ifdef ENABLE_SRP` and `--disable-srp-authentication` is passed to configure, because the whole `lib/srp.c` is guarded with `#ifdef ENABLE_SRP`. I would say this is an issue in the C library and we should provide a stub for `gnutls_srp_server_get_username`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1150649354 You're receiving 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 Oct 27 10:27:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:27:47 +0000 Subject: [gnutls-devel] GnuTLS | includes: define cleanup functions for the use with __attribute__((cleanup)) (!1662) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1662#note_1150740163 That's a good point. I think functions defined with `static inline` are treated similarly as macros, though we probably want a way to ensure backward compatibility. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1662#note_1150740163 You're receiving 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 Oct 27 10:33:44 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:33:44 +0000 Subject: [gnutls-devel] GnuTLS | gnulib: update git submodule (!1509) In-Reply-To: References: Message-ID: Daiki Ueno commented: To avoid some issues with Gnulib, I had to update the base image from Fedora 35 to Fedora 36, where I'm observing that sanitizer builds are taking excessive time to complete. Otherwise the MR should be almost ready. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1509#note_1150749706 You're receiving 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 Oct 27 10:54:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:54:49 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 was reviewed by Zolt?n Fridrich -- Zolt?n Fridrich started a new discussion on lib/x509/privkey_openssl.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1150784418 > - salt.data[i / 2] = x << 4; > + ret = gnutls_hex_decode(&hex_data, salt.data, &salt_size); > + if (ret == GNUTLS_E_PARSING_ERROR) { We probably want a check for other errors (like (ret < 0)) as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 You're receiving 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 Oct 27 10:54:49 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:54:49 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Merge request !1655 was approved by Zolt?n Fridrich Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 Project:Branches: dueno/gnutls:wip/dek-info to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewer: Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655 You're receiving 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 Oct 27 10:54:51 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:54:51 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: Looks good overall. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1150784433 You're receiving 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 Oct 27 10:56:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 08:56:00 +0000 Subject: [gnutls-devel] GnuTLS | Handle private keys with lowercase hex digits in DEK-Info (!1655) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented on a discussion on lib/x509/privkey_openssl.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1150786854 > x = (*c) - '0'; > else if (*c >= 'A' && *c <= 'F') > x = (*c) - 'A' + 10; > + else if (*c >= 'a' && *c <= 'f') I prefer the `gnutls_hex_decode` approach -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1655#note_1150786854 You're receiving 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 Oct 27 12:27:47 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Oct 2022 10:27:47 +0000 Subject: [gnutls-devel] GnuTLS | gnutlsxx: become header-only library (!1622) In-Reply-To: References: Message-ID: Nikolaos Chatzikonstantinou commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1150941669 @dueno I will try this. The library now produces by default a C and a C++ object to link against, with `-DGNUTLSXX_HEADER_ONLY` enabling header-only mode for user projects. Is it preferable to be header-only by default and only produce the C++ object on-demand at the configuration step instead? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1622#note_1150941669 You're receiving 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 Oct 28 10:08:51 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Oct 2022 08:08:51 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) In-Reply-To: References: Message-ID: Simon Josefsson commented: @dueno could you take a look? I have updated the merge request so it builds with latest master. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651#note_1152208638 You're receiving 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 Oct 28 11:02:28 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Oct 2022 09:02:28 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) In-Reply-To: References: Message-ID: Merge request !1651 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651 Project:Branches: jas/gnutls:jas/drop-guile to gnutls/gnutls:master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651 You're receiving 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 Oct 28 11:02:37 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Oct 2022 09:02:37 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) In-Reply-To: References: Message-ID: Daiki Ueno commented: Looks good to me! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651#note_1152281854 You're receiving 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 Oct 28 11:31:53 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Oct 2022 09:31:53 +0000 Subject: [gnutls-devel] GnuTLS | Server initiated TLS 1.2 rehandshake fails due to session tickets (#1421) References: Message-ID: Daiki Ueno created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1421 When the client requests session ticket and has received a NewSessionTicket in the first handshake, the second handshake fails as it waits for NewSessionTicket while the server doesn't indicate sending it. Simple reproducer would be to configure Apache httpd with TLS 1.2 as the maximum protocol version and expose a protected resource as: ``` SSLProtocol all -SSLv3 -TLSv1.3 SSLRequire true SSLVerifyClient require # SSLVerifyDepth 10 # SSLOptions +StdEnvVars ``` and access the resource with gnutls-cli. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1421 You're receiving 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 Oct 31 10:09:16 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 09:09:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: All discussions on merge request !1653 were resolved by Zolt?n Fridrich https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 31 10:43:57 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 09:43:57 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Merge request !1653 was scheduled to merge after pipeline succeeds by Zolt?n Fridrich Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel3 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 31 11:13:11 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 10:13:11 +0000 Subject: [gnutls-devel] GnuTLS | ktls fallback to userspace (#1420) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: I have looked into the kernel code and it seem that the only way to disable the ktls is to close the socket. We are considering a kernel patch that will add a API to disable ktls without closing the socket. In case of a kernel without the forementioned patch, there will be no fallback mechanism, and the session will be simply closed alongside the socket once an error occurs. Enabling GnuTLS-KTLS on kernels without this patch will be discouraged. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1420#note_1154291966 You're receiving 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 Oct 31 11:13:44 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 10:13:44 +0000 Subject: [gnutls-devel] GnuTLS | ktls fallback to userspace (#1420) In-Reply-To: References: Message-ID: Reassigned Issue 1420 https://gitlab.com/gnutls/gnutls/-/issues/1420 Assignee changed to Franti?ek Kren?elok -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1420 You're receiving 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 Oct 31 11:38:09 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 10:38:09 +0000 Subject: [gnutls-devel] GnuTLS | verification error on duplicate server cert in chain (#1335) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich via commit 086e9c4e9bb37c0b6badea3ce615e619b3e38fe2 Issue #1335: https://gitlab.com/gnutls/gnutls/-/issues/1335 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1335 You're receiving 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 Oct 31 11:38:09 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 10:38:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix removal of duplicate certs during verification (!1653) In-Reply-To: References: Message-ID: Merge request !1653 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 Project:Branches: ZoltanFridrich/gnutls:zfridric_devel3 to gnutls/gnutls:master Author: Zolt?n Fridrich Assignee: Zolt?n Fridrich Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1653 You're receiving 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 Oct 31 12:25:43 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 11:25:43 +0000 Subject: [gnutls-devel] GnuTLS | handshake: clear server's session ticket indication at rehandshake (!1663) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1663 Project:Branches: dueno/gnutls:wip/dueno/rehandshake-tickets to gnutls/gnutls:master Author: Daiki Ueno While OpenSSL server doesn't indicate a session ticket in the second handshake of TLS 1.2 rehandshake, GnuTLS client previously waited for it as it didn't clear the internal flag (`session_ticket_renew`) thus the effect remained. This patch clears the flag properly at the end of each handshake. Fixes: #1421 ## 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/1663 You're receiving 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 Oct 31 12:26:00 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 11:26:00 +0000 Subject: [gnutls-devel] GnuTLS | handshake: clear server's session ticket indication at rehandshake (!1663) In-Reply-To: References: Message-ID: Reviewer changed to Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1663 You're receiving 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 Oct 31 12:34:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 11:34:14 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: Invalidate session on ktls error (!1664) 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/1664 You're receiving 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 Oct 31 12:34:15 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 11:34:15 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: Invalidate session on ktls error (!1664) References: Message-ID: Franti?ek Kren?elok created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1664 Project:Branches: FrantisekKrenzelok/gnutls:fix/ktls_fallback to gnutls/gnutls:master Author: Franti?ek Kren?elok Assignee: Franti?ek Kren?elok Reviewer: Daiki Ueno Regarding issue #1420 the fallback mechanism was not properly implemented and additional work is required. Changes introduced by this MR will invalidate the session upon encountering ktls related error. ## 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/1664 You're receiving 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 Oct 31 12:34:14 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 11:34:14 +0000 Subject: [gnutls-devel] GnuTLS | KTLS: Invalidate session on ktls error (!1664) In-Reply-To: References: Message-ID: Reassigned merge request 1664 https://gitlab.com/gnutls/gnutls/-/merge_requests/1664 Assignee changed to Franti?ek Kren?elok -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1664 You're receiving 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 Oct 31 18:32:20 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 17:32:20 +0000 Subject: [gnutls-devel] GnuTLS | ktls fallback to userspace (#1420) In-Reply-To: References: Message-ID: toidiu commented: @FrantisekKrenzelok Thanks for confirming this. I primarily wanted to re-confirm my understanding of the fallback mechanism in the absence of the kernel patch. > Enabling GnuTLS-KTLS on kernels without this patch will be discouraged Yea, unfortunately the documentation on ktls in Linux in not amazing and lacking `key_update` handling means TLS1.3 is not really fully supported. Feel free, to close this issue or keep it around for tracking purposes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1420#note_1154942997 You're receiving 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 Oct 31 21:20:48 2022 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 Oct 2022 20:20:48 +0000 Subject: [gnutls-devel] GnuTLS | Drop guile bindings. See . (!1651) In-Reply-To: References: Message-ID: Merge request !1651 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651 Project:Branches: jas/gnutls:jas/drop-guile to gnutls/gnutls:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1651 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: