From gnutls-devel at lists.gnutls.org Mon Dec 2 10:56:46 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 02 Dec 2024 09:56:46 +0000 Subject: [gnutls-devel] GnuTLS | Client side: unable to detect early data size of UINT32_MAX (#1619) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1619#note_2235944144 Thank you for the report. Indeed, we should change the client side default to 0, or add a flag to indicate the extension is received. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1619#note_2235944144 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 03:53:46 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 02:53:46 +0000 Subject: [gnutls-devel] GnuTLS | Subnet mask analysis (#1596) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2237339116 Sorry for the late response. When running `certtool -i --inder --infile test.der` with `-d10`, I see the following: ```console |<3>| ASSERT: ../../../lib/x509/name_constraints.c[validate_name_constraints_node]:112 |<3>| ASSERT: ../../../lib/x509/name_constraints.c[_gnutls_extract_name_constraints]:171 |<3>| ASSERT: ../../../lib/x509/x509_ext.c[gnutls_x509_ext_import_name_constraints]:425 ``` So the import is actually failing but ignored, resulting in the empty name constraints extension is printed; we should probably print error at import as in [SCTS](https://gitlab.com/gnutls/gnutls/-/blob/403a0e72318388b875e0358c156eed2ab50168e2/lib/x509/output.c). As for verification, it's similar, given the name constraints are empty, it succeeds. However, if you compile gnutls with `--enable-strict-x509`, you would see it is rejected at import time: ```console src/certtool -d2 -i --inder --infile test.der Setting log level to 2 |<2>| error: could not parse extension (2.5.29.30) import error: Error in the certificate. ``` ```console src/certtool -d2 --verify --infile Cases/masktest_n.pem --load-ca-certificate Cases/masktest_n_CA.pem Setting log level to 2 Note that no verification profile was selected. In the future the medium profile will be enabled by default. Use --verify-profile low to apply the default verification of NORMAL priority string. Loaded CAs (1 available) |<2>| error: could not parse extension (2.5.29.30) error parsing CRTs: Error in the certificate. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2237339116 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 08:53:53 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 07:53:53 +0000 Subject: [gnutls-devel] GnuTLS | Client side: unable to detect early data size of UINT32_MAX (#1619) In-Reply-To: References: Message-ID: Stefan Eissing commented: https://gitlab.com/gnutls/gnutls/-/issues/1619#note_2237575453 Thanks for confirming. From my pov, having the session report a 0 unless it receives other information from the server would work nicely. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1619#note_2237575453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 10:03:48 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 09:03:48 +0000 Subject: [gnutls-devel] GnuTLS | Subnet mask analysis (#1596) In-Reply-To: References: Message-ID: dulanshuangqiao commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2237698394 Okay, thank you for your reply. So this is not a bug, is it? You mentioned that we should probably print an error at import as in SCTS Can this be used as an enhancement? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2237698394 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 10:16:03 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 09:16:03 +0000 Subject: [gnutls-devel] GnuTLS | SKI extension with empty values are valid (#1621) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1621 ## Description of problem: RFC5280 defines SKI extension as follows: SubjectKeyIdentifier ::= KeyIdentifier Unlike AKI, all parts of AKI are optional The null SKI extension was considered invalid by Golang, but it was not considered invalid by gnutls and openssl. After my feedback, openssl marked it as a bug. ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one gnutls_x509_crt_import?test.der?[test.der](/uploads/a48fbb88873bd9e0dcdd96fadd515731/test.der) ## Actual results: Complete ## Expected results: invalid subject key identifier -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1621 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 13:00:58 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 12:00:58 +0000 Subject: [gnutls-devel] GnuTLS | Tests are not ready for allow-rsa-pkcs1-encrypt=false (#1622) References: Message-ID: Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1622 > A new option `allow-rsa-pkcs1-encrypt` > has been added into the system-wide library configuration which > allows to enable/disable the RSAES-PKCS1-v1_5. Currently, the > RSAES-PKCS1-v1_5 is enabled by default. According to this NEWS entry, there are future plans to flip the option to false by default. I've tried doing just that with 3.8.8 by flipping the value in lib/priority.c, and the existing testsuite is not ready for this. One easy way to work around this is to run the tests with configs that flip the option back on. For many such tests, this can be attained by a ``` diff --- a/tests/system.prio +++ b/tests/system.prio @@ -1,3 +1,6 @@ HELLO1=NORMAL HELLO2=NORMAL:+AES-128-CBC HELLO3=NONE:+VERS-TLS-ALL:-VERS-SSL3.0:+AEAD:+SHA1:+SHA256:+SHA384:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA:+DHE-DSS:+AES-256-GCM:+AES-256-CBC:+CAMELLIA-256-GCM:+CAMELLIA-256-CBC:+AES-128-GCM:+AES-128-CBC:+CAMELLIA-128-GCM:+CAMELLIA-128-CBC:+3DES-CBC:+SIGN-ALL:-SIGN-RSA-MD5:+CURVE-ALL:+COMP-NULL:%PROFILE_LOW + +[overrides] +allow-rsa-pkcs1-encrypt = true ``` but then several other tests that override the config and try to use, say, RSA kex, need to have an `allow-rsa-pkcs1-encrypt = true` slotted into the `[overrides]` of their overriding configs (`gnutls-cli-debug.sh`, `protocol-set-allowlist.sh`, `system-override-allow-rsa-pkcs1-encrypt.sh`). The list would be even longer when building with full testsuite. I'm afraid the tests should gradually migrate off using RSA kex, made able to override the option back on, or, at least, expect failures when the library is built with the option defaulting to false. The latter currently doesn't look possible, as there's no API to query neither the compile default nor the current effective value. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1622 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 13:53:56 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 12:53:56 +0000 Subject: [gnutls-devel] GnuTLS | x509: print errors when importing name constraints fails (!1902) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1902 Project:Branches: dueno/gnutls:wip/dueno/print-nc-import-error to gnutls/gnutls:master Author: Daiki Ueno * x509: print errors when importing name constraints fails Like printing SCTS, report any error to stdout when iterating over name constraints in a certificate. Fixes: #1596 ## 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/1902 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 13:54:15 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 12:54:15 +0000 Subject: [gnutls-devel] GnuTLS | Subnet mask analysis (#1596) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2238171780 Yes, filed !1902. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1596#note_2238171780 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 14:15:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 13:15:52 +0000 Subject: [gnutls-devel] GnuTLS | Update errors.c (!1899) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238218562 Maybe would you like to resubmit with just the change from "non-properly" to "improperly"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238218562 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 14:37:06 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 13:37:06 +0000 Subject: [gnutls-devel] GnuTLS | Update errors.c (!1899) In-Reply-To: References: Message-ID: Kazooba B Lawrence commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238260626 Sure, let me do that -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238260626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 3 14:41:02 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 03 Dec 2024 13:41:02 +0000 Subject: [gnutls-devel] GnuTLS | Update errors.c (!1899) In-Reply-To: References: Message-ID: Kazooba B Lawrence commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238269151 @asosedkin I have updated as recommended -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1899#note_2238269151 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 4 13:08:56 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 04 Dec 2024 12:08:56 +0000 Subject: [gnutls-devel] GnuTLS | x509: print errors when importing name constraints fails (!1902) In-Reply-To: References: Message-ID: Zolt?n Fridrich was added as a reviewer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1902 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 5 20:34:36 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 05 Dec 2024 19:34:36 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: error if libdane missing on make dist (!1903) References: Message-ID: William Roberts created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1903 Project:Branches: wcrobertarm/gnutls:fix-libdane-missing-dist to gnutls/gnutls:master Author: William Roberts * Makefile.am: error if libdane missing on make dist if libdane is not configured, then make dist will fail with: make[3]: *** No rule to make target 'libdane/libgnutls-dane.la', needed by 'abi-check-latest'. Stop. Now it will fail with: ERROR: Distribution requires libdane, please enable libdane Signed-off-by: Bill Roberts ## 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/1903 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 5 20:35:33 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 05 Dec 2024 19:35:33 +0000 Subject: [gnutls-devel] GnuTLS | make dist fails (#1610) In-Reply-To: References: Message-ID: William Roberts commented: https://gitlab.com/gnutls/gnutls/-/issues/1610#note_2244344886 I think this takes care of part of the issue, a make dist when libdane is not configured. https://gitlab.com/gnutls/gnutls/-/merge_requests/1903 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1610#note_2244344886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 06:57:16 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 05:57:16 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 Project:Branches: dueno/gnutls:wip/dueno/hybrid-kx-liboqs-followup2 to gnutls/gnutls:master Author: Daiki Ueno Previously, the supported_groups array contained externally defined elements, which is legitimate in C99 but caused error with Clang: ``` groups.c:93:2: error: initializer element is not a compile-time constant group_x25519, ^~~~~~~~~~~~ ``` This reworks the array definition of indirection through group IDs (gnutls_group_t, i.e., integer). Fixes: #1604 ## 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/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 07:41:33 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 06:41:33 +0000 Subject: [gnutls-devel] GnuTLS | error: initializer element is not a compile-time constant (#1604) In-Reply-To: References: Message-ID: Reassigned Issue 1604 https://gitlab.com/gnutls/gnutls/-/issues/1604 Daiki Ueno was added as an assignee. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 07:41:31 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 06:41:31 +0000 Subject: [gnutls-devel] GnuTLS | error: initializer element is not a compile-time constant (#1604) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.8.9 (Nov 5, 2024?Jan 5, 2025) ( https://gitlab.com/gnutls/gnutls/-/milestones/47 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 08:20:58 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 07:20:58 +0000 Subject: [gnutls-devel] GnuTLS | --with-included-tasn1 broken (#1616) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1616#note_2244894842 What error do you actually see on the terminal? I can't reproduce it on Fedora 40, after uninstalling libtasn1-devel package: ```console ./configure --disable-doc --disable-shared --with-included-unistring --with-included-libtasn1 --disable-cxx --disable-hardware-acceleartion --without-tpm --without-zlib --without-brotli --without-zstd --without-p11-kit ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1616#note_2244894842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 10:03:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 09:03:13 +0000 Subject: [gnutls-devel] libtasn1 | Update ABI dump files. (!103) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/103 Project:Branches: jas/libtasn1:abi-check-v2 to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 10:04:44 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 09:04:44 +0000 Subject: [gnutls-devel] libtasn1 | Update ABI dump files. (!103) In-Reply-To: References: Message-ID: Merge request !103 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/103 Project:Branches: jas/libtasn1:abi-check-v2 to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 18:22:23 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 17:22:23 +0000 Subject: [gnutls-devel] libtasn1 | Distribute git-archive *-.src.tar.gz and make tarballs reproducible. (!104) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/104 Project:Branches: jas/libtasn1:rop to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/104 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 19:05:33 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 18:05:33 +0000 Subject: [gnutls-devel] libtasn1 | Distribute git-archive *-.src.tar.gz and make tarballs reproducible. (!104) In-Reply-To: References: Message-ID: Merge request !104 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/104 Project:Branches: jas/libtasn1:rop to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/104 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 19:30:58 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 18:30:58 +0000 Subject: [gnutls-devel] libtasn1 | cicd: Add release target. Fix missing bison on macOS. (!105) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/105 Project:Branches: jas/libtasn1:cicd-release to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/105 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 6 20:26:16 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Dec 2024 19:26:16 +0000 Subject: [gnutls-devel] libtasn1 | cicd: Add release target. Fix missing bison on macOS. (!105) In-Reply-To: References: Message-ID: Merge request !105 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/105 Project:Branches: jas/libtasn1:cicd-release to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/105 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 7 10:03:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 07 Dec 2024 09:03:13 +0000 Subject: [gnutls-devel] GnuTLS | Invalid certificate policy extension (#1623) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1623 ## Description of problem: I provided a test case that has a certificate policy extension containing only optional qualifiers without object identifiers, which should be invalid. Golang determined it as follows: invalid certificate policies The description of certificate policy extension is as follows: The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one gnutls_x509_crt_import?Cert.der?[Cert.zip](/uploads/32a792f42788d64d19f48a32a1d27a83/Cert.zip) ## Actual results: Complete ## Expected results: invalid certificate policies -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 7 10:24:51 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 07 Dec 2024 09:24:51 +0000 Subject: [gnutls-devel] GnuTLS | The Extended Key Usage extension should be invalid (#1624) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1624 ## Description of problem: The definition of Extended Key Usage extension is as follows: id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER ASN. 1 specifies that tag 06 represents oid I provided a test case where the enhanced key usage is displayed in non OID content (not OID?tag), which should be invalid. Golang determined it as follows: invalid certificate policies?but gnutls doesn't think so. ![image](/uploads/3ee676aba920188b89f3ed84a25ff879/image.png) ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one gnutls_x509_crt_import?Cert.der?[Cert.zip](/uploads/71920dd9a11c8695b98bef8cc7ac1e50/Cert.zip) ## Actual results: Complete ## Expected results: invalid extended key usages -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1624 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 00:00:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 08 Dec 2024 23:00:52 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: error if libdane missing on make dist (!1903) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on Makefile.am: https://gitlab.com/gnutls/gnutls/-/merge_requests/1903#note_2247347564 > @echo "******************************************************************************************" > > dist-hook: > +if !ENABLE_DANE This would work, though I think the standard place to do this kind of stuff is in `AM_DISTCHECK_CONFIGURE_FLAGS` (adding `--enable-dane` though the current configure script just warns when unbound is missing; we probably should make it `AC_MSG_ERROR` instead of `AC_MSG_WARN`). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1903#note_2247347564 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 08:12:16 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 07:12:16 +0000 Subject: [gnutls-devel] libtasn1 | cicd: Fix macOS job. (!106) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/libtasn1/-/merge_requests/106 Project:Branches: jas/libtasn1:cicd-mac to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/106 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 08:12:43 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 07:12:43 +0000 Subject: [gnutls-devel] libtasn1 | cicd: Fix macOS job. (!106) In-Reply-To: References: Message-ID: Merge request !106 was set to auto-merge by Simon Josefsson Merge request url: https://gitlab.com/gnutls/libtasn1/-/merge_requests/106 Project:Branches: jas/libtasn1:cicd-mac to gnutls/libtasn1:master Author: Simon Josefsson Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 08:26:28 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 07:26:28 +0000 Subject: [gnutls-devel] libtasn1 | cicd: Fix macOS job. (!106) In-Reply-To: References: Message-ID: Merge request !106 was merged Merge request URL: https://gitlab.com/gnutls/libtasn1/-/merge_requests/106 Project:Branches: jas/libtasn1:cicd-mac to gnutls/libtasn1:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/merge_requests/106 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 13:32:58 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 12:32:58 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) References: Message-ID: Stanislav ?idek created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 Project:Branches: ep69/gnutls:interop-fix to gnutls/gnutls:master Author: Stanislav ?idek Assignee: Stanislav ?idek * fix tmt provision -h local ## 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/1905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 13:33:00 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 12:33:00 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Reassigned merge request 1905 https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 Stanislav ?idek was added as an assignee. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 13:35:42 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 12:35:42 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Daiki Ueno was added as a reviewer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 14:22:19 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 13:22:19 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Merge request !1905 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 Project:Branches: ep69/gnutls:interop-fix to gnutls/gnutls:master Author: Stanislav ?idek Assignee: Stanislav ?idek Reviewer: Daiki Ueno -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 14:23:06 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 13:23:06 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Merge request !1905 was set to auto-merge by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 Project:Branches: ep69/gnutls:interop-fix to gnutls/gnutls:master Author: Stanislav ?idek Assignee: Stanislav ?idek Reviewer: Daiki Ueno -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 14:23:03 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 13:23:03 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905#note_2248348171 Thank you, looks like this fixes the failures in the interop tests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905#note_2248348171 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 14:24:14 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 13:24:14 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply), Alexander Sosedkin, and Zolt?n Fridrich were added as reviewers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 15:01:31 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 14:01:31 +0000 Subject: [gnutls-devel] GnuTLS | fix tmt provision -h local (!1905) In-Reply-To: References: Message-ID: Merge request !1905 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 Project:Branches: ep69/gnutls:interop-fix to gnutls/gnutls:master Author: Stanislav ?idek Assignee: Stanislav ?idek Reviewer: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 16:19:59 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 15:19:59 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: error if libdane missing on make dist (!1903) In-Reply-To: References: Message-ID: William Roberts commented on a discussion on Makefile.am: https://gitlab.com/gnutls/gnutls/-/merge_requests/1903#note_2248608271 > @echo "******************************************************************************************" > > dist-hook: > +if !ENABLE_DANE As soon as I submitted this, I thought along the same lines and just haven't gotten back to it. Let me re-spin this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1903#note_2248608271 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 17:22:00 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 16:22:00 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735381 > + return group_is_supported_standalone(group); > + > + for (size_t i = 0; i < NUM_HYBRID_GROUPS; i++) { I'm not sure how would this iteration work, would the limit ever be raised and uneven length `group->ids` appear. -- Alexander Sosedkin started a new discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735393 > - .tls_id = 0x11EB, > - .next = &group_mlkem768 }, > + .ids = { GNUTLS_GROUP_SECP256R1, GNUTLS_GROUP_EXP_MLKEM768 }, Would it be beneficial to NULL-terminate it or store the length? -- Alexander Sosedkin started a new discussion on lib/algorithms.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735397 > #endif > > +#define IS_GROUP_HYBRID(group) ((group)->ids[0] != GNUTLS_GROUP_INVALID) Why are we sure of it being zero-initialized? -- Alexander Sosedkin started a new discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735400 > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) With this definition of supportedness, how does one enable just hybrids or just non-hybrids? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 17:22:00 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 16:22:00 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735409 I liked it more the way it was, kind of simpler and cleaner. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2248735409 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 9 20:57:40 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Dec 2024 19:57:40 +0000 Subject: [gnutls-devel] GnuTLS | Experiment post-quantum key agreement in TLS (#1499) In-Reply-To: References: Message-ID: David Dudas commented: https://gitlab.com/gnutls/gnutls/-/issues/1499#note_2249129457 Is anyone working on this? If not, I would like to work on it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1499#note_2249129457 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 02:09:57 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 01:09:57 +0000 Subject: [gnutls-devel] GnuTLS | Experiment post-quantum key agreement in TLS (#1499) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1499#note_2249741615 This is about key exchange using ML-KEM, which is already implemented; so I guess we can close this issue. With regard to PQC in TLS, one missing feature is signatures at the protocol level, as Alicja mentioned at https://gitlab.com/gnutls/gnutls/-/merge_requests/1786#note_2220755967. If you would like to work on that, that would be awesome and filing a new issue would be a good start. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1499#note_2249741615 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 05:17:42 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 04:17:42 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Daiki Ueno -- Daiki Ueno commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2249852268 > - .tls_id = 0x11EB, > - .next = &group_mlkem768 }, > + .ids = { GNUTLS_GROUP_SECP256R1, GNUTLS_GROUP_EXP_MLKEM768 }, Good idea, I actually included it in the initial version, but removed it given the length is always 2 for now. If we continue using an array, having a NUL terminator would provide more flexibility. -- Daiki Ueno commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2249852274 > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) With a property string, I think it works same as before, e.g., `-GROUP-ALL:+GROUP-X25519-MLKEM768` does enable only the X25519-MLKEM768 group. On the other hand, disabling X25519 now disables X25519-MLKEM768 as well (previously it didn't affect the hybrid group), but I'd say this is rather expected. -- Daiki Ueno commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2249852275 > + return group_is_supported_standalone(group); > + > + for (size_t i = 0; i < NUM_HYBRID_GROUPS; i++) { It's quite hypothetical, but yes, we could support hybrid groups of more than 2 groups if needed. -- Daiki Ueno commented on a discussion on lib/algorithms.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2249852278 > #endif > > +#define IS_GROUP_HYBRID(group) ((group)->ids[0] != GNUTLS_GROUP_INVALID) Because all groups are statically allocated in bss, as part of `supported_groups`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 08:27:51 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 07:27:51 +0000 Subject: [gnutls-devel] GnuTLS | Dereference of null at privkey.c (gnutls version - 3.8.3) (#1579) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1579: https://gitlab.com/gnutls/gnutls/-/issues/1579 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1579 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 08:27:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 07:27:52 +0000 Subject: [gnutls-devel] GnuTLS | Dereference of null at privkey.c (gnutls version - 3.8.3) (#1579) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1579#note_2250106717 The fix has been committed as part of !1894. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1579#note_2250106717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 08:33:39 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 07:33:39 +0000 Subject: [gnutls-devel] GnuTLS | Investigate the performance of FIPS self-tests (#1577) In-Reply-To: References: Message-ID: Reassigned Issue 1577 https://gitlab.com/gnutls/gnutls/-/issues/1577 Daiki Ueno was added as an assignee. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1577 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 09:41:19 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 08:41:19 +0000 Subject: [gnutls-devel] GnuTLS | keyusage extension parsing (#1608) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1608#note_2250227335 We could make the current behavior (reject) in the `--enable-strict-x509` build only, though I don't see the usefulness of allowing it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1608#note_2250227335 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 09:53:47 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 08:53:47 +0000 Subject: [gnutls-devel] GnuTLS | Certificate parsing differences (#1613) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1613: https://gitlab.com/gnutls/gnutls/-/issues/1613 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1613 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 09:53:47 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 08:53:47 +0000 Subject: [gnutls-devel] GnuTLS | Certificate parsing differences (#1613) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1613#note_2250251887 This is not a bug. Parsing of certificate extensions is done in multiple steps: first import the certificate from data with gnutls_x509_crt_import, then retrieve extension data with gnutls_x509_crt_get_extension_data2, and finally decode it with gnutls_x509_ext_import_* functions. In this specific case, you would just need to call gnutls_x509_ext_import_authority_key_id after parsing the certificate data. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1613#note_2250251887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 09:57:57 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 08:57:57 +0000 Subject: [gnutls-devel] GnuTLS | Certificate verification: validity period format check (#1620) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1620#note_2250259729 I don't think this is a bug. RFC 5280 says: > CAs conforming to this profile MUST always encode certificate > validity dates through the year 2049 as UTCTime; certificate validity > dates in 2050 or later MUST be encoded as GeneralizedTime. > Conforming applications MUST be able to process validity dates that > are encoded in either UTCTime or GeneralizedTime. That says, while CA should *use* UTCTime to encode the date, applications that decode the date should be able to process both formats. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1620#note_2250259729 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 10:18:18 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 09:18:18 +0000 Subject: [gnutls-devel] GnuTLS | Certificate verification: validity period format check (#1620) In-Reply-To: References: Message-ID: dulanshuangqiao commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1620#note_2250299209 Yes, thanks for your reply. Since Cryptography has the behavior of checking the format during verification. ![image](/uploads/8880b267c6d1892f80afc889195134fc/image.png) I think this check can be added as an enhancement in gnutls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1620#note_2250299209 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 11:37:01 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 10:37:01 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Alexander Sosedkin -- Alexander Sosedkin commented on a discussion on lib/algorithms.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479843 > #endif > > +#define IS_GROUP_HYBRID(group) ((group)->ids[0] != GNUTLS_GROUP_INVALID) Right. I don't think it's guaranteed to end up in bss, but it looks like zero-initialization is guaranteed. -- Alexander Sosedkin commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479859 > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) I would argue it's not. Since X25519-MLKEM768 is supposed to be stronger than X25519 alone, I can see a case where X25519 ends up broken, but X25519-MLKEM768 is not. Conversely, the inability to turn on X25519-MLKEM768 without turning on X25519 means a downgrade is always allowed, so one wouldn't be able to force use of hybrid. I think hybrid groups should be configurable independently from the underlying groups. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 11:37:01 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 10:37:01 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479868 Currently my only objection is enabling hybrids not being orthogonal to enabling the underlying groups. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 13:21:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 12:21:13 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250694367 The code itself looks good. I wasn't able to find any issues. Not approving as there are unresolved threads. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250694367 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 14:05:11 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 13:05:11 +0000 Subject: [gnutls-devel] GnuTLS | Invalid certificate policy extension (#1623) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply) commented: https://gitlab.com/gnutls/gnutls/-/issues/1623#note_2250788484 > which should be invalid. could you provide the reference to the relevant RFC? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1623#note_2250788484 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 15:06:15 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 14:06:15 +0000 Subject: [gnutls-devel] GnuTLS | Interaction between enabled curves, key exchanges and signature algorithms (#1625) References: Message-ID: Alicja Kario (@mention me if you need reply) created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1625 It looks like the current configuration format isn't able to support all of the following user stories: - US1: I want to use CC-compatible policy, don't want to depend on P-256 for anything, I need hybrids with P-384 or certificates with P-384 - US2: it's far future and ECC is broken by CRQC, but the hybrid key exchanges are widely deployed, so I don't want to trust ECC for signatures but I'm OK with it hybrid key exchanges and signatures (no ECC for certificates, only as part of hybrid) - US3: I want to test deployment of PQC, I want to enable hybrid algorithms now - US4: It's far future, and only pure algorithms are relevant/allowed by regulations, I don't want any hybrid or ECC enabled - US5: only hybrids and pure are allowed and the other peer only speaks hybrid Problematic case: PQ world, we don't want to accept a ECC-only cert, but we're fine with ECC as part of hybrid Solution 1: don't disable hybrid schemes if hybrid scheme is allowed even if one of the underlying primitives is disabled - confusing, counterintuitive for a setting supposed to disable the primitive Solution 2: separate control for curves used in certs, similar to what we have for signatures Solution 3: have the values in a new option (curve-for-pkix?) actually affect what signatures/curves are allowed for _every_ signature in the certificate chain with the ECDSA ? issue: the algorithm IDs in TLS don't create a hard link between hash algorithm and curve for certificate signatures. Only for ECDSA, not EdDSA or post-quantum (curve primitive is enabled, pkix - disabled, groups - disabled => pkix disabled, hybrid enabled, direct usage of primitive is enabled) - Alex Sosedkin: if secure-sig-for-cert *relaxes* secure-sig (does it?), but curve-for-pkix relaxes secure-curve, that'd be inconsistent -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/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 Tue Dec 10 15:06:38 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 14:06:38 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply) commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250930114 > + return NULL; > + > + GNUTLS_GROUP_LOOP(if (p->id == group) { return p; }); > + > + return NULL; > +} > + > +static inline bool > +group_is_supported_standalone(const gnutls_group_entry_st *group) > +{ > + return group->pk != 0 && _gnutls_pk_exists(group->pk) && > + (group->curve == 0 || > + _gnutls_ecc_curve_is_supported(group->curve)); > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) I've filed #1625 to follow up on this -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250930114 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 15:09:54 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 14:09:54 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Alexander Sosedkin -- Alexander Sosedkin commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250937010 > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) Discussed out-of-band, and woo, it's complicated. Turns out I was confusing `tls-enabled-group` with `enabled-curve`. We want orthogonality on the groups level, but that doesn't mean the curve primitive switch shouldn't disable the entire hybrid scheme. It can. The good news are, looks like we can land it as is, with `enabled-curve` disabling a curve precluding the use of the affected hybrid group. This seems to be expected behaviour if `enabled-curve` is a primitive killswitch. The bad news are, this still leaves at least one important use case uncovered, and that is a scenario when we consider a curve is broken, we need negotiating it as part of hybrid because that's widely deployed, but we don't want, say, trusting an intermediate ECC cert in the chain using that group. Unfortunately, that'd require a separate RFE for a separate option or something. I've asked @tomato42 to file one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 15:09:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 14:09:55 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250937026 After being educated on curve vs group switch distinction, I'm dropping my previous objection. See the discussion above for the extra features we'd need to implement to get better at disabling curve usage without throwing the hybrid out with the bathwater in the process. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250937026 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 10 15:09:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Dec 2024 14:09:55 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request !1904 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 Project:Branches: dueno/gnutls:wip/dueno/hybrid-kx-liboqs-followup2 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alicja Kario (@mention me if you need reply), Alexander Sosedkin, and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 02:53:06 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 01:53:06 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: All discussions on merge request !1904 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 02:53:04 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 01:53:04 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2252025338 > + return NULL; > + > + GNUTLS_GROUP_LOOP(if (p->id == group) { return p; }); > + > + return NULL; > +} > + > +static inline bool > +group_is_supported_standalone(const gnutls_group_entry_st *group) > +{ > + return group->pk != 0 && _gnutls_pk_exists(group->pk) && > + (group->curve == 0 || > + _gnutls_ecc_curve_is_supported(group->curve)); > +} > + > +static inline bool group_is_supported(const gnutls_group_entry_st *group) Let's continue on #1625. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2252025338 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 02:53:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 01:53:13 +0000 Subject: [gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904) In-Reply-To: References: Message-ID: Merge request !1904 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 Project:Branches: dueno/gnutls:wip/dueno/hybrid-kx-liboqs-followup2 to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alicja Kario (@mention me if you need reply), Alexander Sosedkin, and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 03:02:44 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 02:02:44 +0000 Subject: [gnutls-devel] GnuTLS | Invalid certificate policy extension (#1623) In-Reply-To: References: Message-ID: dulanshuangqiao commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1623#note_2252031990 RFC5280? 4.2.1.4. Certificate Policies The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation PolicyInformation ::= SEQUENCE { policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL } -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1623#note_2252031990 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 04:38:06 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 03:38:06 +0000 Subject: [gnutls-devel] GnuTLS | Not able to build latest 'master' on ubuntu 20.04 (#1626) References: Message-ID: Rajib Sen created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1626 ## Description of problem: I wanted to try PQC support added recently . I have been trying to build latest master branch on ubuntu 20.04 but getting below error- eaas at eaas-PC:~/gnutls$ sudo ./configure --prefix=/usr/lib64 ...... checking for getrandom... yes checking for KERN_ARND... no checking for getentropy... no checking for NETTLE... no configure: error: *** *** Libnettle 3.6 was not found. -------- I have nettle installed - eaas at eaas-PC:~/gnutls$ ls /usr/lib64/ bin ld-linux-x86-64.so.2 libhogweed.so libhogweed.so.6.0 libnettle.so.8 pkgconfig include lib64 libhogweed.so.6 libnettle.so libnettle.so.8.0 share ## Version of gnutls used: ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) ## How reproducible: Steps to Reproduce: * one * two * three ## Actual results: Not able to build ## Expected results: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 08:00:57 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 07:00:57 +0000 Subject: [gnutls-devel] GnuTLS | Not able to build latest 'master' on ubuntu 20.04 (#1626) In-Reply-To: References: Message-ID: Rajib Sen commented: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2252473701 please find config.log attached. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2252473701 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 08:00:34 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 07:00:34 +0000 Subject: [gnutls-devel] GnuTLS | Not able to build latest 'master' on ubuntu 20.04 (#1626) In-Reply-To: References: Message-ID: Rajib Sen commented: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2252473364 [config.log](/uploads/bac714d17b134096864e40dea0053242/config.log) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2252473364 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 18:16:33 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 17:16:33 +0000 Subject: [gnutls-devel] GnuTLS | Not able to build latest 'master' on ubuntu 20.04 (#1626) In-Reply-To: References: Message-ID: Issue was closed by Andreas Metzler Issue #1626: https://gitlab.com/gnutls/gnutls/-/issues/1626 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 11 18:16:36 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Dec 2024 17:16:36 +0000 Subject: [gnutls-devel] GnuTLS | Not able to build latest 'master' on ubuntu 20.04 (#1626) In-Reply-To: References: Message-ID: Andreas Metzler commented: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2254036588 Well, the error message was `Libnettle 3.6 was not found.` and looking at config.log we find ``` configure:13022: checking for NETTLE configure:13029: $PKG_CONFIG --exists --print-errors "nettle >= $NETTLE_MINIMUM" Requested 'nettle >= 3.6' but version of Nettle is 3.5.1 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1626#note_2254036588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 12 15:09:10 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 12 Dec 2024 14:09:10 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Set default value of early date size for client to 0 (!1906) References: Message-ID: Sahil Siddiq created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 Project:Branches: valdaarhun/gnutls:client_early_data_size to gnutls/gnutls:master Author: Sahil Siddiq Set the default value of `early_data_size` to 0 for the client. `early_data_size` is set to a non-zero value when the server [sends the relevant extension](https://gitlab.com/gnutls/gnutls/-/blob/master/lib/tls13/session_ticket.c#L464) in a session ticket to the client. Gitlab issue: https://gitlab.com/gnutls/gnutls/-/issues/1619 ## 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/1906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 12 15:13:37 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 12 Dec 2024 14:13:37 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Sahil Siddiq commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2255804612 Regarding the test suite, I am not sure if a new test be added that checks the value of "early_data_size" when the server supports/doesn't support it, or if [tests/tls13-early-data.c](https://gitlab.com/gnutls/gnutls/-/blob/master/tests/tls13-early-data.c) should be modified. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2255804612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 12 22:29:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 12 Dec 2024 21:29:55 +0000 Subject: [gnutls-devel] GnuTLS | Investigate the performance of FIPS self-tests (#1577) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1577#note_2256702895 perf shows that the most significant part is in the PBKDF2 self-tests (see below), which we run a test with 80000 iterations. Skipping that test alone makes it 50% faster already. The other costly test is test_dh, though I don't think we can make any optimization for it. The rest (e.g., cipher tests) are fast enough, though there are some redundancies (e.g., testing for multiple modes for AES). ```console GNUTLS_FORCE_FIPS_MODE=1 GNUTLS_CPUID_OVERRIDE=0x0 NETTLE_FAT_OVERRIDE=none perf record -F 999 -a -g -e cycles --call-graph lbr --user-callchains src/gnutls-cli --list perf report -G -n --stdio [...] 62.65% 62.65% 85 gnutls-cli libnettle.so.8.8 > | |--33.58%--nettle_pbkdf2 | | | |--32.88%--nettle_hmac_digest | | | | | |--32.12%--nettle_sha256_digest | | | 0x7f5b1645a300 | | | nettle_sha256_compress at plt | | | | | --0.76%--nettle_sha256_update | | _nettle_sha256_compress_n at plt | | | --0.70%--nettle_sha256_update | _nettle_sha256_compress_n at plt | |--12.73%--check_lib_hmac | gnutls_hmac_fast | _gnutls_mac_fast | wrap_nettle_mac_fast | nettle_sha256_update | _nettle_sha256_compress_n at plt | |--7.24%--_gnutls_fips_perform_self_checks2 | | | |--6.48%--test_pbkdf2.constprop.0 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1577#note_2256702895 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 13 03:25:17 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 13 Dec 2024 02:25:17 +0000 Subject: [gnutls-devel] GnuTLS | Is GNUTLS still using CRL? (#1627) References: Message-ID: Qianxin Cheng created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1627 Hello developer, I am a beginner, and I couldn't find any CRL-related APIs in the GNUTLS documentation. Could you please let me know if GNUTLS is still using CRL? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 13 04:52:20 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 13 Dec 2024 03:52:20 +0000 Subject: [gnutls-devel] GnuTLS | Is GNUTLS still using CRL? (#1627) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1627#note_2257075504 Yes, you can use CRL for checking certificate validity, e.g., with `gnutls_x509_trust_list_add_crls`. The documentation is at: https://www.gnutls.org/manual/html_node/PKIX-certificate-revocation-lists.html#PKIX-certificate-revocation-lists https://www.gnutls.org/manual/html_node/Verifying-X_002e509-certificate-paths.html -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1627#note_2257075504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 13 08:21:02 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 13 Dec 2024 07:21:02 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2257224149 Thank you for the MR @valdaarhun. I think modifying the existing test would be simpler as it requires session resumption and writing it from scratch wouldn't be straightforward. I guess it would be sufficient to cover the following scenarios: - `gnutls_session_get_max_early_data` returns 0 for client, before/after the initial connection - `gnutls_session_get_max_early_data` returns the server advertised value for client, after the session is resumed (this should already be covered) - `gnutls_session_get_max_early_data` return 0 for client, after the session is resumed but no "early_data" extension was negotiated -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2257224149 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 13 18:28:19 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 13 Dec 2024 17:28:19 +0000 Subject: [gnutls-devel] GnuTLS | Query : PQC support (#1628) References: Message-ID: Rajib Sen created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1628 I am new to using gnuTLS . I have been trying to check PQC support made available by using gnuTLS along with libmicrohttpd . In the sample REST server i have set group and cipher as below - MHD_start_daemon (..... MHD_OPTION_HTTPS_PRIORITIES, "NORMAL:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:-CIPHER-ALL:+AES-256-GCM:-KX-ALL:+AEAD:+SHA384:+SIGN-ALL:**-GROUP-ALL:+GROUP-X25519-KYBER768:**+GROUP-GOST-ALL:+CIPHER-GOST-ALL:+MAC-GOST-ALL:+SIGN-GOST-ALL", MHD_OPTION_END); With this , server doesn't come up , port doesnt come up listening. When "-GROUP-ALL:+GROUP-X25519-KYBER768:" is excluded , server comes up fine with classical capabilities. I am using latest master branch code , locally built on ubuntu 20.04. Am i missing anything? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Dec 15 18:35:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 15 Dec 2024 17:35:52 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Sahil Siddiq commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2260144285 Thank you for your reply. > * `gnutls_session_get_max_early_data` return 0 for client, after the session is resumed but no "early_data" extension was negotiated > > The last one is a bit tricky and you might need to actually write a new test, or modify other tests, such as tests/tls13-early-data-neg\*.c. I think writing a new test will be better for this scenario since the server side is initialized with `GNUTLS_ENABLE_EARLY_DATA` in tests/tls13-early-data-neg\*.c. Based on what I have understood, the server in this scenario shouldn't be initialized with `GNUTLS_ENABLE_EARLY_DATA`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2260144285 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 16 01:48:03 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 16 Dec 2024 00:48:03 +0000 Subject: [gnutls-devel] GnuTLS | Query : PQC support (#1628) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2260242495 Hello Rajib, the PQC algorithms are currently marked as experimental and need to be enabled in multiple places, at build time and run time. You might first want to check whether the group is available by running `src/gnutls-cli --list`. If the X25519Kyber768Draft00 group is available, you will see something like: ```console Groups: GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-GC256B, GROUP-GC512A, GROUP-X448, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192, GROUP-MLKEM768, GROUP-KYBER768, GROUP-SECP256R1-MLKEM768, GROUP-X25519-MLKEM768, GROUP-X25519-KYBER768 ``` I would also suggest using X25519MLKEM768 or SecP256r1MLKEM768, which are defined in an active [draft](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/). See the pqc-hybrid-kx.sh [test](https://gitlab.com/gnutls/gnutls/-/blob/5f92e8df5121c4fe4892099240bcbafd679db8ed/tests/pqc-hybrid-kx.sh) for details. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2260242495 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Dec 16 06:38:25 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 16 Dec 2024 05:38:25 +0000 Subject: [gnutls-devel] GnuTLS | Query : PQC support (#1628) In-Reply-To: References: Message-ID: Rajib Sen commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2260384092 Hi Daiki , Thank you for replying! Appreciate your good work! Any available documents or write up on how to enable PQC support while building ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2260384092 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 11:59:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 10:59:55 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907 Project:Branches: dueno/gnutls:wip/dueno/post-optimize to gnutls/gnutls:master Author: Daiki Ueno * crypto-selftests-pk: skip negative tests by default * fips: skip compat API tests in AES self-tests * fips: perform RSA self-tests using RSA-PSS instead of PKCS#1 v1.5 Previously the RSA self-tests were using PKCS#1 v1.5, for both signature generation and encryption/decryption, which turned a bit problematic as GnuTLS now has a run-time option to disable that scheme. According to FIPS 140-3 IG 10.3.A, for each FIPS 186-4 and FIPS 186-5 public key digital signature algorithm, a CAST shall be performed using at least one of the schemes approved for use in the approved mode. Similarly, the IG annex D.G mentions that if the RSA signature generation algorithm and RSA un-encapsulation scheme use the same implementation, only test for signature generation suffices. Therefore, this switches to using RSA-PSS only and drop the RSA encryption/decryption self-tests. * fips: defer PBKDF2 self-tests until the algorithm is actually used FIPS 140-3 allows the module to perform self-tests for an algorithm at any time before the algorithm is used. Since PBKDF2 self-tests are costly, this defers them until gnutls_pbkdf2 is called for the first time. * fips: defer EdDSA self-tests until the algorithm is actually used FIPS 140-3 allows the module to perform self-tests for an algorithm at any time before the algorithm is used. This defers them until the key generation, signing, or signature verification actually happens. Note that deferring self-tests for other public key algorithms is not straightforward, because some of those algorithms change the internal implementation based on whether the library is running the self-tests or not, while we can't easily switch the library into that state in later phases. For example, RSA self-tests switch the RNG to be a deterministic version. * fips: defer DH self-tests until the algorithm is actually used FIPS 140-3 allows the module to perform self-tests for an algorithm at any time before the algorithm is used. Since DH self-tests are costly, this defers them until the key generation or derivation actually happens. * fips: only run the first test vector for each symmetric algorithm FIPS 140-3 doesn't require to run multiple test vectors for a single algorithm, and one of the test vector for PBKDF2, with an 80000 iteration count is known to be too costly. Therefore, this patch changes gnutls_*_self_test to pick only the first test from the test vectors, unless GNUTLS_SELF_TEST_FLAG_ALL is specified. The existing test vectors have been reviewed and modified for the first element to use the sane parameters, namely: aes128_gcm_vectors to use non-zero key and non-empty AAD, aes256_gcm_vectors to use non-empty AAD, and pbkdf2_sha256_vectors to use iteration count greater than 1. * fips: run AES-256 self-tests with only a single mode Previously we ran FIPS power-on self-tests for AES-256-CBC, AES-256-GCM, AES-256-XTS, and AES-256-CFB8, though only one mode per key size suffices according to FIPS 140-3 IG. This omits AES-256-CBC, AES-256-XTS, and AES-256-CFB8, keeping AES-256-GCM for performance. Fixes: #1577 #1490 ## 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/1907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 12:17:56 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 11:17:56 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1907 was reviewed by Clemens Lang -- Clemens Lang started a new discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2262785412 > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); Just to make sure, this does perform a self-test for signature creation *and* verification, correct? Both are required in order to skip the test for encapsulation and decapsulation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 13:10:53 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 12:10:53 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2262879934 > } > > /* PK */ > - if (_gnutls_config_is_rsa_pkcs1_encrypt_allowed()) { > - ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA); > - if (ret < 0) { > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); Yes, that's correct; `gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS)` does perform signature generation and [verification](https://gitlab.com/gnutls/gnutls/-/blob/5f92e8df5121c4fe4892099240bcbafd679db8ed/lib/crypto-selftests-pk.c#L489). Oh, however, it's not KAT anymore. I'll add a test vector there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2262879934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 14:05:42 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 13:05:42 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Clemens Lang commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2262976881 > } > > /* PK */ > - if (_gnutls_config_is_rsa_pkcs1_encrypt_allowed()) { > - ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA); > - if (ret < 0) { > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); PSS is probabilistic, though, will you be able to add a KAT in that case? I guess you could set the salt length to 0 to make PSS deterministic, although that kind of defeats its purpose. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2262976881 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 14:08:53 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 13:08:53 +0000 Subject: [gnutls-devel] GnuTLS | Is GNUTLS still using CRL? (#1627) In-Reply-To: References: Message-ID: Issue was closed by Zolt?n Fridrich Issue #1627: https://gitlab.com/gnutls/gnutls/-/issues/1627 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 16:05:04 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 15:05:04 +0000 Subject: [gnutls-devel] GnuTLS | Query : PQC support (#1628) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2263265825 As mentioned in the NEWS file, you would need to specify the `--with-liboqs` option at the `configure` command line. For this to work, however, liboqs 0.11 or later has to be installed on the system, though it seems liboqs in Debian is a bit [behind](https://tracker.debian.org/pkg/liboqs). Most likely you would need to compile it by yourself and adjust the build-time flags (e.g., `PKG_CONFIG_PATH`) so the GnuTLS build infrastructure can find it. I can create a write-up, but in the long run we will probably migrate to a native implementation which doesn't require liboqs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2263265825 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Dec 17 17:42:48 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 17 Dec 2024 16:42:48 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Clemens Lang started a new discussion on lib/crypto-selftests-pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2263532238 > if (sig.size != ssig.size || > memcmp(sig.data, ssig.data, sig.size) != 0) { > ret = GNUTLS_E_SELF_TEST_ERROR; > -#if 0 > +#if 1 I guess this is just for testing purposes at the moment and will change back to `#if 0`? LG2M, then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2263532238 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 13:23:21 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 12:23:21 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/crypto-selftests-pk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2264995841 > if (sig.size != ssig.size || > memcmp(sig.data, ssig.data, sig.size) != 0) { > ret = GNUTLS_E_SELF_TEST_ERROR; > -#if 0 > +#if 1 Thanks; fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2264995841 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 13:26:54 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 12:26:54 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2265003639 > } > > /* PK */ > - if (_gnutls_config_is_rsa_pkcs1_encrypt_allowed()) { > - ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA); > - if (ret < 0) { > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); Yeah, but we already use a deterministic RNG for the RSA PKCS#1 v1.5 self-tests (for blinding), so that might apply to this as well. @smuellerDD do you have any insights here? Does it make sense and is it allowed to use a deterministic RNG for the KAT of RSA-PSS? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2265003639 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 16:07:15 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 15:07:15 +0000 Subject: [gnutls-devel] GnuTLS | Query : PQC support (#1628) In-Reply-To: References: Message-ID: Rajib Sen commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2265431987 Following mentioned steps , looks like i am able to build gnutls with PQC enabled -- eaas at eaas-PC:~/gnutls$ src/gnutls-cli --list | egrep -i "(kyber|kem)768" Groups: GROUP-SECP192R1, GROUP-SECP224R1, GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-GC256B, GROUP-GC512A, GROUP-X448, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192, GROUP-MLKEM768, GROUP-KYBER768, GROUP-SECP256R1-MLKEM768, GROUP-X25519-MLKEM768, GROUP-X25519-KYBER768 Public Key Systems: RSA, RSA-PSS, RSA-OAEP, RSA, DSA, GOST R 34.10-2012-512, GOST R 34.10-2012-256, GOST R 34.10-2001, EC/ECDSA, EdDSA (Ed25519), EdDSA (Ed448), DH, ECDH (X25519), ECDH (X448), ML-KEM-768, KYBER768, ML-DSA-44, ML-DSA-65, ML-DSA-87 Leaving this thread open for two more days in case i need help while testing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1628#note_2265431987 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 19:04:15 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 18:04:15 +0000 Subject: [gnutls-devel] GnuTLS | Draft: Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 was reviewed by Sahil Siddiq -- Sahil Siddiq commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2265909200 Hi, I think I misunderstood how "early data" is negotiated. I spent some time understanding the implementation of early data, session tickets and tests/tls13-early-data-neg*.c. My understanding is that "early data" is negotiated when the server sends a session ticket with the relevant extension rather than simply being initialized with `GNUTLS_ENABLE_EARLY_DATA`. I have modified tests/tls13-early-data-neg2.c instead of creating a new test. The test currently makes use of 2 sessions to check that "early data" is rejected by the server when resumption fails (in the current case because the first session ticket key is overwritten). This test now establishes 3 sessions instead of 2. No session ticket is sent during the first session to negotiate "early data". Due to this, "max_early_data_size" for the client is 0 after resumption is attempted in the second session. The second and third sessions together perform the checks done in the original test. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 19:06:00 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 18:06:00 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Sahil Siddiq marked merge request !1906 as ready -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Dec 18 20:21:17 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 19:21:17 +0000 Subject: [gnutls-devel] GnuTLS | build gnutls with msvc in the ci (gitgub action) (#1630) References: Message-ID: Tal Regev created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1630 Build gnutls with msvc in the ci (gitgub action) similar to osx. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1630 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 00:19:32 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 23:19:32 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) References: Message-ID: Tal Regev created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908 Project:Branches: tal.regev/gnutls:TalR/cmake to gnutls/gnutls:master Author: Tal Regev * add cmake ## 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/1908 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 00:19:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 18 Dec 2024 23:19:52 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Merge request !1908 was closed by Tal Regev Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908 Project:Branches: tal.regev/gnutls:TalR/cmake to gnutls/gnutls:master Author: Tal Regev Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 02:19:38 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 01:19:38 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2266499490 Great that you figured out that! Could you clear the commit-check issue so the rest of the CI pipeline run? Apply the changes suggested [here](https://gitlab.com/valdaarhun/gnutls/-/jobs/8676584307#L53) or run `devel/indent-gnutls` script if you have a compatible version of clang-format. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2266499490 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 02:21:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 01:21:13 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Merge request !1906 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 Project:Branches: valdaarhun/gnutls:client_early_data_size to gnutls/gnutls:master Author: Sahil Siddiq Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 07:58:02 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 06:58:02 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: All discussions on merge request !1906 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 07:58:28 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 06:58:28 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Merge request !1906 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 Project:Branches: valdaarhun/gnutls:client_early_data_size to gnutls/gnutls:master Author: Sahil Siddiq -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 07:58:20 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 06:58:20 +0000 Subject: [gnutls-devel] GnuTLS | Set default value of early date size for client to 0 (!1906) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2266867580 Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1906#note_2266867580 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 08:18:14 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 07:18:14 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Stephan Mueller commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2266898192 > } > > /* PK */ > - if (_gnutls_config_is_rsa_pkcs1_encrypt_allowed()) { > - ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA); > - if (ret < 0) { > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); It is perfectly legitimate to use a "deterministic" RNG as part of the self test to perform a KAT. You can also use a hard-coded "random" value instead. However, what I would like to ask is, now that the enc/dec is dropped, is the enc/dec being covered via OAEP? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2266898192 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 09:39:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 08:39:55 +0000 Subject: [gnutls-devel] GnuTLS | Certificate Validation Differences (#1631) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1631 ## Description of problem: For the two certificates I provided, both contained the SKI extension, but the value was 0. Both certificates failed the verification of openssl, while the verification results of gnutls showed differences Cert1732784125104D1.pem passed the verification of gnutls, while Cert1732784125103D1.pem failed. ![image](/uploads/c93287e15534ca531c2bd8c25970b38b/image.png){width=368 height=84} [Cert1732784125103D1.pem](/uploads/5351f8d3b3e4f1f4b96879ef9d9898a6/Cert1732784125103D1.pem) [Cert1732784125104D1.pem](/uploads/7f5060c2693583a16f75c96fa8cd3d10/Cert1732784125104D1.pem) [RootCA.pem](/uploads/a0a2ea07153e02b987bdc9746ff14303/RootCA.pem) ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one certtool --verify --load-ca-certificate RootCA.pem --infile Cert1732784125103D1.pem * two certtool --verify --load-ca-certificate RootCA.pem --infile Cert1732784125104D1.pem ## Actual results: Cert1732784125104D1.pem?Verified, The certificate is trusted. Cert1732784125103D1.pem?Not verified. The certificate is NoT trusted. ## Expected results: Cert1732784125104D1.pem?Not verified. The certificate is NoT trusted. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 10:33:49 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 09:33:49 +0000 Subject: [gnutls-devel] GnuTLS | Optimize FIPS power-on self-tests (!1907) In-Reply-To: References: Message-ID: Clemens Lang commented on a discussion on lib/fips.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2267119149 > } > > /* PK */ > - if (_gnutls_config_is_rsa_pkcs1_encrypt_allowed()) { > - ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA); > - if (ret < 0) { > - return gnutls_assert_val(GNUTLS_E_SELF_TEST_ERROR); > - } > + ret = gnutls_pk_self_test(0, GNUTLS_PK_RSA_PSS); We're removing that, in favor of the signature and signature verification self test. FIPS 140-3 IG D.G has this on the matter: > If an RSA signature generation algorithm and an approved RSA-based key un-encapsulation scheme are both supported by the module using the same implementation (same hardware, same code for the RSA primitive computations) and the module is performing the signature generation self-test then it is not necessary to also perform a self-test for the key un-encapsulation scheme, as long as the signature generation CAST is performed prior to the first use of the signature generation or key un-encapsulation functions. > > Similarly, if the same implementation performs the common functionality for both the RSA signature verification and an approved RSA-based key encapsulation scheme then it is sufficient to perform a CAST just for the signature verification algorithm, as long as the signature verification CAST is performed prior to the first use of the signature verification or key encapsulation functions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1907#note_2267119149 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 20:54:14 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 19:54:14 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Merge request !1908 was reopened by Tal Regev Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908 Project:Branches: tal.regev/gnutls:TalR/cmake to gnutls/gnutls:master Author: Tal Regev Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 21:05:08 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 20:05:08 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Tal Regev commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268357813 After a discottion in https://gitlab.com/gnutls/gnutls/-/issues/320 I decided to create a PR to add a small compilation of the code in cmake. This is a skeleton PR that can take and build up slowly the cmake build system. I am not against Meson, I just more familiar with cmake. Anyone can take this PR and continue / replace the work to fill the need for new build system. What I did with cmake, can be done similar with Meson. This PR use the autoconf build system to compile. Because it needed the headers that it create. For not using the header the code will needed to change. This is not aim this PR and the follow. Only when the new build system will be large enough to replace autoconf, we can consider to change the code for that. That is the big problem to replace autoconf. It needed to change to code to remove it. That why it cannot replace with one commit, and do a fork just for replace it just to much work. (the same just to do one big change of ci). The new build system need to build slowly side by side to autoconf, and live with the code. The code is dynamic change, and the build system need to adapt to that as well. That why also the ci is needed and important. That why I added a compilation test in the ci. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268357813 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 21:29:06 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 20:29:06 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Eli Schwartz started a new discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268376645 > This PR use the autoconf build system to compile. Because it needed the headers that it create. For not using the header the code will needed to change. This is not aim this PR and the follow. Only when the new build system will be large enough to replace autoconf, we can consider to change the code for that. This is *exactly* why even considering to change the build system is a complicated issue that needs real discussion. Requiring *both* autoconf and cmake to build is, IMHO, unacceptable and a total nonstarter. The actual hard part of a port to another build system is when you try to remove those assumptions. This MR doesn't contain anything reviewable, to be perfectly honest. All it has is the boilerplate that could be written in a few minutes if the GnuTLS developers eventually wanted to commit to using cmake. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268376645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 21:36:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 20:36:13 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Tal Regev commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268382047 I don't agree it not reviewable. Even this PR is not a renewable (maybe this the word you wanted to write) and not give a breakthrough to replace the autoconf build system. First it explain the problem to other people. Second, it covered the other option to do it (in one commit or fork). Third, it not against other new build system like Meson. Forth, it give other people a tool to start build and continue this work. If you will think why replace autoconf is not doable, you will end up stay with auto conf. But if you really think how you can do it, you will get the conclusion that it needed to be build system that will grow along side with autoconf. > Requiring _both_ autoconf and cmake to build is, IMHO, unacceptable and a total nonstarter. You say unacceptable and not total nonstarter and you don't explain your reason and suggest other ways. Also I show here is a starter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268382047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 23:01:08 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 22:01:08 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Tal Regev commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268443831 As I say you can take my code and continue and make it more useful and more useable. or create it by your own. meanwhile the issue is 4 year long without any actual step in the direction to replace. I will love to learn from you and see how to move away large project from autoconf. If you can do stater PR it will be great ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268443831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Dec 19 23:48:12 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 19 Dec 2024 22:48:12 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Eli Schwartz commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268438284 > Tal Regev commented on a discussion > : > > I don't agree it not reviewable. Even this PR is not a renewable (maybe > this the word you wanted to write) and not give a breakthrough to replace > the autoconf build system. > I'm not sure what you're saying here but I definitely used the word I intended to use, which is "reviewable" and not "renewable". I don't know what a "renewable" MR is, but a reviewable MR is one that can be reviewed by by maintainers and a prerequisite of that is that there is something available to review. First it explain the problem to other people. > It doesn't explain the problem to other people. The only problem I'm aware of is that: - the feature has not been accepted - a reliance on gnulib means that porting is inherently challenging as you need to also port gnulib or stop using gnulib Both are explained sufficiently in the linked issue. Neither are explained in this MR (using ./configure as part of cmake doesn't demonstrate any challenge, it simply demonstrates that no attempt was made to implement it). Assuming I accept for the sake of argument that this MR explains "the problem", the purpose of an issue is to explain a problem and the purpose of an MR is to propose a solution. If all this does is explain a problem and not propose a solution then why isn't this an issue instead? Second, it covered the other option to do it (in one commit or fork). > What is "it" that is being done? This doesn't build gnutls. Third, it not against other new build system like Meson. > At no point did I criticize this MR by saying I would rather meson, so I'm not sure what you are replying to. Forth, it give other people a tool to start build and continue this work. > I assert my belief that this doesn't provide anything for people to build on, because this MR doesn't contain any code to build GnuTLS, just boilerplate that would take a few minutes to reimplement correctly in a serious attempt to port the real configuration logic over. If you will think why replace autoconf is not doable, you will end up stay > with auto conf. But if you really think how you can do it, you will get the > conclusion that it needed to be build system that will grow along side with > autoconf. > As I've helped several projects move away from autotools I'm quite aware of how to do it, and you absolutely do need to keep both of them alongside each other for a while, but the first step *has* to be something that is actually usable, which this is not. This doesn't even build GnuTLS! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2268438284 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 20 01:45:22 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 20 Dec 2024 00:45:22 +0000 Subject: [gnutls-devel] GnuTLS | certtool: generated PKCS8 private keys inconsistent with RFC (#1632) References: Message-ID: Samuel Chiang created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1632 ## Description of problem: gnu-tls/certtool outputs a PKCS8 file that's not coherent with RFC8018 Appendix A.2: https://datatracker.ietf.org/doc/html/rfc8018#appendix-A.2 The RFC states that the PBKDF2-PRF Algorithm identifier should have a NULL field paired with the algorithm id to be used. algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::= {algorithm id-hmacWithSHA1, parameters NULL : NULL} The pkcs8 files I've generated with gnu-tls using `PBES2_AES_128` are missing this NULL field, which causes a parsing error in [AWS-LC](https://github.com/aws/aws-lc/blob/f45bc34b9132fbd7749c45431fa06a89198cdb4b/crypto/pkcs8/p5_pbev2.c#L292-L300) & [BoringSSL](https://github.com/google/boringssl/blob/be21ef7012f0812bb1c0c8fc226979fa6c301e8d/crypto/pkcs8/p5_pbev2.cc#L292-L300) due to their stricter checks. Just as additional sanity test, the PKCS8 files I've generated with OpenSSL don't have this issue and correctly generate a PKCS8 file with the NULL field paired with the algorithm id. * OpenSSL command: `openssl pkcs8 -in rsa_key_file.pem -topk8 -v2 aes-128-cbc -out output.p8 -passout pass:abcedf` ### Side note: When running `certtool --to-p8 ... pkcs-cipher=...`, is `PKCS12_3DES_SHA1` the intended default? I noticed that there was this older commit 14 years ago that tried changing the default to `AES-128`: https://gitlab.com/gnutls/gnutls/-/commit/0d004a210db5d220c896456a165c81264fa4454a. That was changed a couple years later when some parts of `certtool` were reworked in https://gitlab.com/gnutls/gnutls/-/commit/d0ae20f780ac74857d70b4190166bf18195ef4d7. `pkcs_cipher` in the certtool application code doesn't have a default value assigned, which causes the [default `PKCS12_3DES_SHA1` schema](https://gitlab.com/gnutls/gnutls/-/blob/d0ae20f780ac74857d70b4190166bf18195ef4d7/lib/x509/privkey_pkcs8.c#L412-434) to be used instead. There isn't any explicit documentation on what the default for `pkcs-cipher` is however, I was more or less genuinely curious since the behavior's slightly inconsistent with past release notes and the commit history. ## Version of gnutls used: gnutls-cli 3.6.13 Although this issue still seems to exist in gnutls today when looking at the relevant code here: https://gitlab.com/gnutls/gnutls/-/blob/master/lib/x509/pkcs7-crypt.c#L1349-1363 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: 1. Use a RSA private key to load into certtool and output a pkcs8 file: ``` certtool --load-privkey=rsa_key_file.pem --to-p8 --password=abcdef --pkcs-cipher=aes-128 ``` 2. There's a nifty tool called [der2ascii](https://github.com/google/der-ascii) that helps dump out all the ASN.1 contents of a file. ``` der2ascii -pem -i their-old-rsa-key.pem > their-old-rsa.txt ``` ## Actual results: These are the ASN.1 contents of the PBKDF2 identifier I got: ``` SEQUENCE { # PBKDF2 OBJECT_IDENTIFIER { 1.2.840.113549.1.5.12 } SEQUENCE { OCTET_STRING { `b1322c8a7ae134caf8a30533730606801d25` } INTEGER { `0927c0` } INTEGER { 16 } SEQUENCE { # hmacWithSHA256 OBJECT_IDENTIFIER { 1.2.840.113549.2.9 } } } } ``` ## Expected results: These are the ASN.1 contents I got from OpenSSL. Notice the `NULL {}` field paired along with the `hmacWithSHA256` OID. ``` SEQUENCE { # PBKDF2 OBJECT_IDENTIFIER { 1.2.840.113549.1.5.12 } SEQUENCE { OCTET_STRING { `5b57711e03a7c6bc` } INTEGER { 2048 } SEQUENCE { # hmacWithSHA256 OBJECT_IDENTIFIER { 1.2.840.113549.2.9 } NULL {} } } } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Dec 20 18:58:07 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 20 Dec 2024 17:58:07 +0000 Subject: [gnutls-devel] GnuTLS | support: DTLS connection ID (#801) In-Reply-To: References: Message-ID: Sahil Siddiq commented: https://gitlab.com/gnutls/gnutls/-/issues/801#note_2269888105 Hi, I came across this issue from the [projects for newcomers](https://gitlab.com/gnutls/gnutls/-/wikis/Projects-for-newcomers) wiki. This seems like a very interesting task and I would like to work on this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/801#note_2269888105 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 03:43:57 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 02:43:57 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) References: Message-ID: Maxim Cournoyer created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 Project:Branches: apteryks/gnutls:add-bison-to-bootstrap-conf-buildreq to gnutls/gnutls:master Author: Maxim Cournoyer bootstrap.conf: Require the 'bison' command. * bootstrap.conf (buildreq): Add bison. Fixes: ## 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) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 06:15:39 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 05:15:39 +0000 Subject: [gnutls-devel] GnuTLS | Building the bundled gnulib test suite fails (#1633) References: Message-ID: Maxim Cournoyer created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1633 ## Description of problem: Building from the master branch, using the following dependencies: gcc 11.4.0 libtool 2.4.7 autoconf 2.71 automake 1.16.5 After running ./bootstrap && ./configure, `make` fails (see below for log output). ## Version of gnutls used: Lastest master branch (commit 436a69e01). ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) GNU Guix but N/A here. ## How reproducible: Steps to Reproduce: 1. Clone project 2. Setup build environment: I used GNU Guix for that: `guix shell --pure -D gnutls libev gperf gettext gtk-doc bison autoconf automake libtool git-minimal perl wget` ## Actual results: ``` Making all in tests make[4]: Entering directory '/home/maxim/src/gnutls/src/gl/tests' ## ---------------------------------------------------- ## ## ------------------- Gnulib tests ------------------- ## ## You can ignore compiler warnings in this directory. ## ## ---------------------------------------------------- ## make all-recursive make[5]: Entering directory '/home/maxim/src/gnutls/src/gl/tests' Making all in . make[6]: Entering directory '/home/maxim/src/gnutls/src/gl/tests' make[6]: Nothing to be done for 'all-am'. make[6]: Leaving directory '/home/maxim/src/gnutls/src/gl/tests' make[5]: Leaving directory '/home/maxim/src/gnutls/src/gl/tests' make[4]: Leaving directory '/home/maxim/src/gnutls/src/gl/tests' make[3]: Leaving directory '/home/maxim/src/gnutls/src/gl' make[2]: Leaving directory '/home/maxim/src/gnutls/src/gl' Making all in src make[2]: Entering directory '/home/maxim/src/gnutls/src' make all-am make[3]: Entering directory '/home/maxim/src/gnutls/src' CC psk.o In file included from psk.c:42: psk.c: In function 'main': psktool-options.h:1:30: warning: implicit declaration of function 'process_options' [-Wimplicit-function-declaration] 1 | #define optionProcess(a,b,c) process_options(b,c) | ^~~~~~~~~~~~~~~ psk.c:84:9: note: in expansion of macro 'optionProcess' 84 | optionProcess(&psktoolOptions, argc, argv); | ^~~~~~~~~~~~~ psktool-options.h:1:30: warning: nested extern declaration of 'process_options' [-Wnested-externs] 1 | #define optionProcess(a,b,c) process_options(b,c) | ^~~~~~~~~~~~~~~ psk.c:84:9: note: in expansion of macro 'optionProcess' 84 | optionProcess(&psktoolOptions, argc, argv); | ^~~~~~~~~~~~~ psk.c:86:14: warning: implicit declaration of function 'HAVE_OPT'; did you mean 'HAVE_PIPE'? [-Wimplicit-function-declaration] 86 | if (!HAVE_OPT(PSKFILE)) { | ^~~~~~~~ | HAVE_PIPE psk.c:86:14: warning: nested extern declaration of 'HAVE_OPT' [-Wnested-externs] psk.c:86:23: error: 'PSKFILE' undeclared (first use in this function); did you mean 'FILE'? 86 | if (!HAVE_OPT(PSKFILE)) { | ^~~~~~~ | FILE psk.c:86:23: note: each undeclared identifier is reported only once for each function it appears in psk.c:90:26: warning: implicit declaration of function 'OPT_ARG' [-Wimplicit-function-declaration] 90 | passwd = OPT_ARG(PSKFILE); | ^~~~~~~ psk.c:90:26: warning: nested extern declaration of 'OPT_ARG' [-Wnested-externs] psk.c:92:23: error: 'USERNAME' undeclared (first use in this function) 92 | if (!HAVE_OPT(USERNAME)) { | ^~~~~~~~ psk.c:109:22: error: 'KEYSIZE' undeclared (first use in this function) 109 | if (HAVE_OPT(KEYSIZE) && OPT_VALUE_KEYSIZE > MAX_KEY_SIZE) { | ^~~~~~~ psk.c:109:34: error: 'OPT_VALUE_KEYSIZE' undeclared (first use in this function) 109 | if (HAVE_OPT(KEYSIZE) && OPT_VALUE_KEYSIZE > MAX_KEY_SIZE) { | ^~~~~~~~~~~~~~~~~ make[3]: *** [Makefile:3305: psk.o] Error 1 make[3]: Leaving directory '/home/maxim/src/gnutls/src' make[2]: *** [Makefile:3065: all] Error 2 make[2]: Leaving directory '/home/maxim/src/gnutls/src' make[1]: *** [Makefile:2878: all-recursive] Error 1 make[1]: Leaving directory '/home/maxim/src/gnutls' make: *** [Makefile:2803: all] Error 2 ``` ## Expected results: `make` should succeed and exit with status 0. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 06:16:48 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 05:16:48 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270350452 Looks like wget is also required on master branch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270350452 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 08:35:19 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 07:35:19 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270547019 Here's the full compiler command line leading to the failure: ``` make[3]: Entering directory '/home/maxim/src/gnutls/src' depbase=`echo psk.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -I. -I.. -I./gl -I./gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./../extra/includes -I/gnu/store/2y46v8isd9n57zs4hc5j8rjbd38s4zqd-libtasn1-4.19.0/include -fanalyzer -Wall -Wbad-function-cast -Wcast-align=strict -Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-branches -Wduplicated-cond -Wextra -Winit-self -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd -Wpacked -Wpointer-arith -Wshadow -Wstrict-prototypes -Wsuggest-attribute=cold -Wsuggest-attribute=format -Wsuggest-attribute=malloc -Wsuggest-final-methods -Wsuggest-final-types -Wsync-nand -Wtrampolines -Wuninitialized -Wunknown-pragmas -Wunused-macros -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Warray-bounds=2 -Wattribute-alias=2 -Wformat-overflow=2 -Wformat=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wunused-const-variable=2 -Wvla-larger-than=4031 -Wno-analyzer-malloc-leak -Wno-missing-field-initializers -Wno-unused-parameter -Wno-format-truncation -Wimplicit-fallthrough=2 -Wabi=11 -fdiagnostics-show-option -fno-builtin-strcmp -g -O2 -MT psk.o -MD -MP -MF $depbase.Tpo -c -o psk.o psk.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from psk.c:42: psk.c: In function 'main': psktool-options.h:1:30: warning: implicit declaration of function 'process_options' [-Wimplicit-function-declaration] 1 | #define optionProcess(a,b,c) process_options(b,c) | ^~~~~~~~~~~~~~~ psk.c:84:9: note: in expansion of macro 'optionProcess' 84 | optionProcess(&psktoolOptions, argc, argv); | ^~~~~~~~~~~~~ psktool-options.h:1:30: warning: nested extern declaration of 'process_options' [-Wnested-externs] 1 | #define optionProcess(a,b,c) process_options(b,c) | ^~~~~~~~~~~~~~~ psk.c:84:9: note: in expansion of macro 'optionProcess' 84 | optionProcess(&psktoolOptions, argc, argv); | ^~~~~~~~~~~~~ psk.c:86:14: warning: implicit declaration of function 'HAVE_OPT'; did you mean 'HAVE_PIPE'? [-Wimplicit-function-declaration] 86 | if (!HAVE_OPT(PSKFILE)) { | ^~~~~~~~ | HAVE_PIPE psk.c:86:14: warning: nested extern declaration of 'HAVE_OPT' [-Wnested-externs] psk.c:86:23: error: 'PSKFILE' undeclared (first use in this function); did you mean 'FILE'? 86 | if (!HAVE_OPT(PSKFILE)) { | ^~~~~~~ | FILE psk.c:86:23: note: each undeclared identifier is reported only once for each function it appears in psk.c:90:26: warning: implicit declaration of function 'OPT_ARG' [-Wimplicit-function-declaration] 90 | passwd = OPT_ARG(PSKFILE); | ^~~~~~~ psk.c:90:26: warning: nested extern declaration of 'OPT_ARG' [-Wnested-externs] psk.c:92:23: error: 'USERNAME' undeclared (first use in this function) 92 | if (!HAVE_OPT(USERNAME)) { | ^~~~~~~~ psk.c:109:22: error: 'KEYSIZE' undeclared (first use in this function) 109 | if (HAVE_OPT(KEYSIZE) && OPT_VALUE_KEYSIZE > MAX_KEY_SIZE) { | ^~~~~~~ psk.c:109:34: error: 'OPT_VALUE_KEYSIZE' undeclared (first use in this function) 109 | if (HAVE_OPT(KEYSIZE) && OPT_VALUE_KEYSIZE > MAX_KEY_SIZE) { | ^~~~~~~~~~~~~~~~~ ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270547019 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 08:37:48 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 07:37:48 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270547375 `configure` says I'm building with PSK support: ` PSK support: yes` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270547375 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 09:12:18 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 08:12:18 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270553261 Thank you! I somehow forgot to follow up on this after commenting on #1196. Looking at m4/parse-datetime.m4, it seems to require bison >= [2.4](https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/parse-datetime.m4#n44). Could you specify the version as the minimum requirement? (Also could you clear the commit-check error in the CI, which indicates there is a mismatch on the `Signed-off-by:` line and the commit author). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270553261 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 09:12:40 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 08:12:40 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Merge request !1909 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 Project:Branches: apteryks/gnutls:add-bison-to-bootstrap-conf-buildreq to gnutls/gnutls:master Author: Maxim Cournoyer Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 09:19:13 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 08:19:13 +0000 Subject: [gnutls-devel] GnuTLS | support: DTLS connection ID (#801) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/801#note_2270554248 @valdaarhun it would be awesome if you could work on this. Note that the connection ID extension is natively [supported](https://www.rfc-editor.org/rfc/rfc9147.html#name-connection-id-updates) in DTLS 1.3, which is currently being worked on at !1667. Maybe you could first talk to @FrantisekKrenzelok to coordinate the effort. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/801#note_2270554248 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 09:22:51 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 08:22:51 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270554751 Seems HAVE_OPT is never defined? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270554751 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 10:36:16 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 09:36:16 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270563978 Could you share the complete build log as well as `config.log`? I suspect that [cligen](https://gitlab.com/gnutls/cligen) is not working for some reason, e.g., submodules are not initialized (try `git clone --recurse-submodules` in that case), or missing Python interpreter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270563978 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 13:12:32 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 12:12:32 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270647723 I'm using `guix shell --pure -D gnutls libev gperf gettext gtk-doc bison python autoconf automake git-minimal wget libtool perl` now, so I have python3 on PATH (correctly detected by configure). Config.log is attached and so is the complete build log. [config.log](/uploads/5f52b038baa7effc488ef961b4c1358c/config.log) [gnutls-failed-build.log](/uploads/9cdb7f1ff4527274c3e364b69895e43a/gnutls-failed-build.log) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270647723 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 13:14:01 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 12:14:01 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270652342 running `git submodule update --recursive` prints nothing, so it seems my git submodules are already initialized correctly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270652342 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 13:20:15 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 12:20:15 +0000 Subject: [gnutls-devel] GnuTLS | Build failure when building from git (#1633) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270671304 Oh! After runnning `git clean -xfdd`, I can now successfully build. So I guess in my initial attempts Python was not available, and somehow the build system cached something that would be reused. I'll add `python` to the buildreq of bootstrap.conf in a PR I've opened. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1633#note_2270671304 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 13:25:52 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 12:25:52 +0000 Subject: [gnutls-devel] GnuTLS | add cmake (!1908) In-Reply-To: References: Message-ID: Maxim Cournoyer commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2270689772 @tal.regev I don't see any arguments about *why* this would be useful or needed? Seems it's following the trendy 'migrate Autotools to the X newfangled build system' hobby. The strongest arguments I've heard for CMake are "it auto-generates project files for Windows!", which leaves me wanting more, especially for a GNU package. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1908#note_2270689772 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 14:58:58 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 13:58:58 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Maxim Cournoyer commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270731431 Hi! I've made the change for bison. I think the signed-of-by trailers are now OK. I've moved the python check to configure.ac since it's not used during bootstrap but at build time when building from git (and when running the full test suite). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270731431 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 14:59:57 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 13:59:57 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: All discussions on merge request !1909 were resolved by Maxim Cournoyer https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 16:25:21 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 15:25:21 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests when dependencies are missing (to merge after MR #1909: bootstrap.conf: Require the 'bison' command.) (!1910) References: Message-ID: Maxim Cournoyer created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910 Project:Branches: apteryks/gnutls:add-missing-test-skip-conditions to gnutls/gnutls:master Author: Maxim Cournoyer build: Skip tls-fuzzer when python-six is not available. * configure.ac [HAVE_PYTHON_SIX]: New conditional. * tests/suite/Makefile.am (scripts_to_test) [HAVE_PYTHON_SIX]: Conditionally include tls-fuzzer test scripts. ~~ tests: Skip multi-ticket-reception test when valgrind is not available. This test would hang when attempting to run without valgrind available. * tests/suite/multi-ticket-reception.sh: Skip when VALGRIND is not set. ## 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) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 16:25:45 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 15:25:45 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270744103 Just to be clear, this should be merged before https://gitlab.com/gnutls/gnutls/-/merge_requests/1910 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909#note_2270744103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 23:37:35 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 22:37:35 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: Require the 'bison' command. (!1909) In-Reply-To: References: Message-ID: Merge request !1909 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 Project:Branches: apteryks/gnutls:add-bison-to-bootstrap-conf-buildreq to gnutls/gnutls:master Author: Maxim Cournoyer -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 23:40:33 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 22:40:33 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests when dependencies are missing (to merge after MR #1909: bootstrap.conf: Require the 'bison' command.) (!1910) In-Reply-To: References: Message-ID: Merge request !1910 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910 Project:Branches: apteryks/gnutls:add-missing-test-skip-conditions to gnutls/gnutls:master Author: Maxim Cournoyer Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 23:40:55 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 22:40:55 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests when dependencies are missing (to merge after MR #1909: bootstrap.conf: Require the 'bison' command.) (!1910) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910#note_2270839400 LGTM, thank you. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910#note_2270839400 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Dec 21 23:41:11 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 21 Dec 2024 22:41:11 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests when dependencies are missing (to merge after MR #1909: bootstrap.conf: Require the 'bison' command.) (!1910) In-Reply-To: References: Message-ID: Merge request !1910 was set to auto-merge by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910 Project:Branches: apteryks/gnutls:add-missing-test-skip-conditions to gnutls/gnutls:master Author: Maxim Cournoyer Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Dec 22 02:10:29 2024 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 22 Dec 2024 01:10:29 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests when dependencies are missing (to merge after MR #1909: bootstrap.conf: Require the 'bison' command.) (!1910) In-Reply-To: References: Message-ID: Maxim Cournoyer commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910#note_2270863635 Hi! The tls-fuzzer/tls-fuzzer-nolimit.sh test failed in the CI; is it flaky, perhaps? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1910#note_2270863635 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: