From gnutls-devel at lists.gnutls.org Sat Mar 1 14:51:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Mar 2025 13:51:09 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/issues/31#note_2373988580 The following 29 sign algorithms are missing from the latest gnutls (3.8.9) rsa-sha224 dsa-sha224 dsa-sha256 ecdsa-sha1 ecdsa-sha224 ecdsa-sha256 ecdsa-sha384 ecdsa-sha512 dsa-sha384 dsa-sha512 ecdsa-sha3-224 ecdsa-sha3-256 ecdsa-sha3-384 ecdsa-sha3-512 dsa-sha3-224 dsa-sha3-256 dsa-sha3-384 dsa-sha3-512 rsa-sha3-224 rsa-sha3-256 rsa-sha3-384 rsa-sha3-512 rsa-raw gost-94 gost-256 gost-512 mldsa44 mldsa65 mldsa87 It seems like the `tests/list-sign-algorithms.scm` is doing a bad job catching this because it is passing while a lot of values are missing. I also found some missing pk-algorithms (which the list-pk-algorithm test found). mlkem768 mldsa44 mldsa65 mldsa87 mlkem1024 Is there a better way than manually checking the gnutls.h header and comparing? Also I am a bit confused on the ordering in `guile/modules/gnutls/modules/build/enums.scm` and the export in `guile/modules/gnutls.in` . I would expect the order to match the order from the enum but with the sign-algorithms at least it does not hold true making it difficult to compare with the enum declaration . Havent checked other enums for completeness. Some of these have only been introduced in recent gnutls versions but the GNUTLS_SIGN_ECDSA_SHA256 from my certificate has been available in gnutls since version 2.99.2 (released 2011-05-26). Maybe this can be automated in some way? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31#note_2373988580 You're receiving 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 Mar 1 16:34:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Mar 2025 15:34:12 +0000 Subject: [gnutls-devel] GnuTLS | [Experimental] Enable MLDSA at TLS 1.3 level (!1938) References: Message-ID: David Dudas created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938 Project:Branches: d-Dudas/gnutls:ddudas/enable-tls-mldsa to gnutls/gnutls:master Author: David Dudas [Experimental] Enable MLDSA at TLS 1.3 level Signed-off-by: David Dudas ## 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/1938 You're receiving 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 Mar 1 20:04:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 01 Mar 2025 19:04:18 +0000 Subject: [gnutls-devel] Guile-GnuTLS | year 2038 problem in x509-certificate-*-time (#32) References: Message-ID: Dariqq created an issue: https://gitlab.com/gnutls/guile/-/issues/32 Hello, I was looking at certificate with the guile api and noticed a 2k38 problem with the activation and expiration dates: `cert.pem` is a (self-signed) certificate that expires in 2055: ```scm (use-modules (gnutls) (ice-9 binary-ports)) (let* ((data (call-with-input-file "cert.pem" get-bytevector-all)) (cert (import-x509-certificate data x509-certificate-format/pem))) (format #t "Activation: ~a~%Expiration: ~a~%" (strftime "%c" (gmtime (x509-certificate-activation-time cert))) (strftime "%c" (gmtime (x509-certificate-expiration-time cert))))) ``` Output: ``` Activation: Fri Feb 21 18:31:34 2025 Expiration: Thu Jan 16 12:03:18 1919 ``` Output from `gnutls_x509_crt_print` from gnutls (3.8.9) on the same host: ``` Validity: Not Before: Fr Feb 21 18:31:34 UTC 2025 Not After: So Feb 21 18:31:34 UTC 2055 ``` I am on a x86_64 machine -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/32 You're receiving 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 Mar 2 11:20:19 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 02 Mar 2025 10:20:19 +0000 Subject: [gnutls-devel] Guile-GnuTLS | year 2038 problem in x509-certificate-*-time (#32) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/issues/32#note_2374215747 This might not be a problem with guile-gnutls but rather with gnutls itself as the `time_t` value returned by `gnutls_x509_crt_get_expiration_time` is already negative, and `scm_from_int` just converts that to `SCM`. Trying to use the `set-*!` variants with a big or small enough time value leads to a gnutls exception: ```scm (use-modules (gnutls)) (let ((cert (make-x509-certificate)) (expiration (expt 2 31))) (set-x509-certificate-expiration-time! cert expiration)) ;; In procedure raise exception: ;; Value out of range -2147483648 to< 2147483647: 2147483648 ``` Which are `-2^31` and `2^31 - 1` and Not sure where things get truncated to 32bits. I'll report to them -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/32#note_2374215747 You're receiving 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 Mar 2 12:31:31 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 02 Mar 2025 11:31:31 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) References: Message-ID: Dariqq created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1670 ## Description of problem: Originally a bug against the guile bindings (https://gitlab.com/gnutls/guile/-/issues/32) but i think it might be an issue with gnutls. The functions `gnutls_x509_crt_get_expiration_time`, `gnutls_x509_crt_set_expiration_time`, `gnutls_x509_crt_get_activation_time`, `gnutls_x509_crt_set_activation_time` seem to have troubles using time values greater than 32 bits. Trying to get a time value results in an overflow/underflow, trying to set a value in an error. I am using a 64bit system. ## Version of gnutls used: 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Verified this on Fedora 41, Debian 13 and others (on x86_64) ## How reproducible: Always ## Steps to Reproduce: I am using my scheme examples from the other bug report, but I verified that this is not an issue with the bindings as the value is already negative before it gets converted to a scheme value Setting a value: ```scm (use-modules (gnutls)) (let ((cert (make-x509-certificate)) (expiration (expt 2 31))) (set-x509-certificate-expiration-time! cert expiration)) ``` Getting: The file `cert.pem` has an expiry date in 2055 ``` (use-modules (gnutls) (ice-9 binary-ports)) (let* ((data (call-with-input-file "cert.pem" get-bytevector-all)) (cert (import-x509-certificate data x509-certificate-format/pem))) (format #t "Activation: ~a~%Expiration: ~a~%" (strftime "%c" (gmtime (x509-certificate-activation-time cert))) (strftime "%c" (gmtime (x509-certificate-expiration-time cert))))) ``` Similar issues with the activation time ## Actual results: Setting: ``` An error: In procedure raise exception: Value out of range -2147483648 to< 2147483647: 2147483648 ``` Getting ``` Activation: Fri Feb 21 18:31:34 2025 Expiration: Thu Jan 16 12:03:18 1919 ``` ## Expected results: Set the date to the correct time. Get the correct timestamp for expiration/activation. Interestingly when I use `gnutls_x509_crt_print` the dates are correct: ``` Validity: Not Before: Fri Feb 21 18:31:34 UTC 2025 Not After: Sun Feb 21 18:31:34 UTC 2055 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670 You're receiving 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 Mar 3 09:04:11 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Mar 2025 08:04:11 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS reject a critical Policy Mappings (#1671) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1671 ## Description of problem: GnuTLS reject a cert with critical PolicyMappings.However OpenSSL accept it.According to RFC 5280, the ext PolicyMappings should be marked as critical. ## Version of gnutls used: gnutls-cli 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one certtool --verify --load-ca-certificate RootCA.pem --infile Cert17408146207.pem [Cert17408146207.pem](/uploads/93d737f30c252d1e31cc02c358ad326c/Cert17408146207.pem) [RootCA.pem](/uploads/89cc125c6597254bd0efca6f04746945/RootCA.pem) ## Actual results: ``` Loaded CAs (1 available) Subject: CN=www.mycompany1.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Issuer: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Checked against: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Signature algorithm: RSA-SHA256 Output: Not verified. The certificate is NOT trusted. The certificate contains an unknown critical extension. Chain verification output: Not verified. The certificate is NOT trusted. The certificate contains an unknown critical extension. ``` ## Expected results: Verified. The certificate is trusted. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1671 You're receiving 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 Mar 3 13:06:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Mar 2025 12:06:05 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS accepts a critical Subject Key Identifier (#1672) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1672 ## Description of problem: GnuTLS accepts a critical Subject Key Identifier. OpenSSL and WolfSSL reject it. RFC 5280 requires the ext SKI must be marked as non-critical. ## Version of gnutls used: gnutls-cli 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one certtool --verify --load-ca-certificate RootCA.pem --infile Cert17408142963.pem [Cert17408142963.pem](/uploads/7163941bc5e98a343961839ab277cd27/Cert17408142963.pem)[RootCA.pem](/uploads/2eef74ceb38fe45241449d368ea4fe4a/RootCA.pem) ## Actual results: ``` Loaded CAs (1 available) Setting log level to 10 Subject: CN=www.mycompany1.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Issuer: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Checked against: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Signature algorithm: RSA-SHA256 Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. ``` ## Expected results: Consistent verification results among GnuTLS and other TLS implementations. OpenSSL?error 34 at 0 depth lookup: unhandled critical extension WolfSSL:wolfSSL_CertManagerVerify failed with return code -160 and error message X.509 Critical extension ignored or invalid -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1672 You're receiving 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 Mar 3 13:23:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 03 Mar 2025 12:23:10 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS accepted certificate with wrong value for Keyusage extension (#1673) References: Message-ID: dulanshuangqiao created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1673 ## Description of problem: GnuTLS accepted certificate with wrong value for Keyusage extension.WolfSSL believes that the key usage value of the certificate is wrong. The key usage value is: cRLSign, keyAgreement, decipherOnly, nonRepudiation, dataEncipherment, keyCertSign (critical=True). According to RFC5280 (section 4.2.1.3), the keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted. ## Version of gnutls used: gnutls-cli 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one certtool --verify --load-ca-certificate RootCA.pem --infile Cert17408145466.pem [Cert17408145466.pem](/uploads/93373540eb7d0a1eeaf9438fae97d70f/Cert17408145466.pem) [RootCA.pem](/uploads/15249761053afba0f63a86587f3db6e5/RootCA.pem) ## Actual results: ``` Loaded CAs (1 available) Setting log level to 10 Subject: CN=www.mycompany1.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Issuer: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Checked against: CN=www.mycompany.com,OU=My Unit1,O=My Company1,L=MY Locality1,ST=My ST1,C=UN Signature algorithm: RSA-SHA256 Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. ``` ## Expected results: Not verified. The certificate is NOT trusted. WolfSSL:wolfSSL_CertManagerVerify failed with return code -226 and error message Key Usage value error -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1673 You're receiving 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 Mar 4 13:27:06 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 12:27:06 +0000 Subject: [gnutls-devel] GnuTLS | Country field with more than two English characters. (#1674) References: Message-ID: Qianxin Cheng created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1674 ## Description of problem: Hello Developer, I have a CRL file where the Country value in the Issuer field is "USA." Normally, ISO 3166-1 specifies two characters to represent a country name. However, GnuTLS successfully printed the Issuer field information of this CRL file without any errors. Therefore, I would like to ask if this is a bug. ## Version of gnutls used: GnuTLS 3.7.11 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile USA_Country.der ## Actual results: GnuTLS successfully printed this CRL file. ## Expected results: For comparison, when using Python's Cryptography library to print this CRL file, the following error was displayed: error: must be >= 2 and <= 2, but it was 3. [USA_Country.der](/uploads/453ebed1da954300e5b20e151fcdb32b/USA_Country.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1674 You're receiving 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 Mar 4 14:07:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 13:07:23 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378170061 > I verified that this is not an issue with the bindings as the value is already negative before it gets converted to a scheme value Could you please share how you checked that? Or, perhaps, a guile-less reproducer for the issue? I recall we've tested that quite a while ago and GnuTLS returned a 64-bit time_t... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378170061 You're receiving 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 Mar 4 14:13:52 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 13:13:52 +0000 Subject: [gnutls-devel] GnuTLS | [Experimental] Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply) started a new discussion on lib/priority.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2378184880 > GNUTLS_SIGN_RSA_SHA1, > GNUTLS_SIGN_ECDSA_SHA1, > > + GNUTLS_SIGN_MLDSA44, > + GNUTLS_SIGN_MLDSA65, > + GNUTLS_SIGN_MLDSA87, those should be listed first, so that when server has configured both classical certs and PQC, that PQC gets negotiated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2378184880 You're receiving 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 Mar 4 17:03:55 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 16:03:55 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378607994 I added a print statement in the guile code after the call to gnutls_x509_crt_get_expiration_time and before it gets converted back to scheme. It looks something like this ```c gnutls_x509_crt_t c_cert; time_t c_time; c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); c_time = gnutls_x509_crt_get_expiration_time (c_cert); printf("%ld\n", c_time); // c_time has already overflown here. return scm_from_int (c_time); ``` This made me think that it is not an issue with the bindings. The exception for setting a value should just correspond to a gnutls error which hints at the same issue. However I am unable to reproduce this when i use C directly: ```c #include #include #include // gcc -o main main.c -lgnutls int main () { int err; gnutls_x509_crt_t cert; time_t time = 2147483648; // 2^31 err = gnutls_x509_crt_init (&cert); if(err == 0) { printf("%ld\n", time); err = gnutls_x509_crt_set_expiration_time(cert, time); printf("%d: %s\n", err, gnutls_strerror(err)); } } // ./main // 2147483648 // 0: Success ``` Also I am when I try to read my certificate and get the expiration time directly from C `gnutls_x509_crt_get_expiration_time` returns the correct time of 2686847494. So a scheme problem after all? Apologies for the false alarm. I am very confused on what is happening. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378607994 You're receiving 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 Mar 4 17:21:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 16:21:51 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378655748 Maybe the C code in guile-gnutls was built with 32-bit time_t? That could explain things. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378655748 You're receiving 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 Mar 4 17:51:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 16:51:39 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378723237 I think I made a mistake: when I checked 2 days ago i accidentally casted to int and when I redid it now I was looking at the wrong output of my test program. gnutls indeed seems to return the correct value. maybe the scm_from_int/scm_to_int in the 4 get/set functions are at fault? Not sure why this causes the weird error message in the `set-*`variants which suggests to me that gnutls gets the full number. But I also dont know how `scm_to_int` works when it is trying to convert an arbitrary size guile integer to int. In guile sources I found ``` #if SCM_SIZEOF_INT == 4 #define scm_to_int scm_to_int32 #define scm_from_int scm_from_int32 #define scm_to_uint scm_to_uint32 #define scm_from_uint scm_from_uint32 #else #if SCM_SIZEOF_INT == 8 #define scm_to_int scm_to_int64 #define scm_from_int scm_from_int64 #define scm_to_uint scm_to_uint64 #define scm_from_uint scm_from_uint64 #else #error sizeof(int) is not 4 or 8. #endif #endif ``` On my system `SCM_SIZEOF_INT` is `4` so guile seems to convert to/from int32_t -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378723237 You're receiving 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 Mar 4 18:01:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 17:01:37 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Issue was moved to another project. New issue location: https://gitlab.com/gnutls/guile/-/issues/33 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670 You're receiving 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 Mar 4 18:01:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 17:01:22 +0000 Subject: [gnutls-devel] GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#1670) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378746395 That looks suspicies. You can't put a time_t in an int. Is there a `scm_from_long`? I think this issue should be moved to guile-gnutls, I'll see if I can do that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1670#note_2378746395 You're receiving 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 Mar 4 18:01:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 17:01:37 +0000 Subject: [gnutls-devel] Guile-GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#33) References: Message-ID: Dariqq created an issue: https://gitlab.com/gnutls/guile/-/issues/33 ## Description of problem: Originally a bug against the guile bindings (https://gitlab.com/gnutls/guile/-/issues/32) but i think it might be an issue with gnutls. The functions `gnutls_x509_crt_get_expiration_time`, `gnutls_x509_crt_set_expiration_time`, `gnutls_x509_crt_get_activation_time`, `gnutls_x509_crt_set_activation_time` seem to have troubles using time values greater than 32 bits. Trying to get a time value results in an overflow/underflow, trying to set a value in an error. I am using a 64bit system. ## Version of gnutls used: 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Verified this on Fedora 41, Debian 13 and others (on x86_64) ## How reproducible: Always ## Steps to Reproduce: I am using my scheme examples from the other bug report, but I verified that this is not an issue with the bindings as the value is already negative before it gets converted to a scheme value Setting a value: ```scm (use-modules (gnutls)) (let ((cert (make-x509-certificate)) (expiration (expt 2 31))) (set-x509-certificate-expiration-time! cert expiration)) ``` Getting: The file `cert.pem` has an expiry date in 2055 ``` (use-modules (gnutls) (ice-9 binary-ports)) (let* ((data (call-with-input-file "cert.pem" get-bytevector-all)) (cert (import-x509-certificate data x509-certificate-format/pem))) (format #t "Activation: ~a~%Expiration: ~a~%" (strftime "%c" (gmtime (x509-certificate-activation-time cert))) (strftime "%c" (gmtime (x509-certificate-expiration-time cert))))) ``` Similar issues with the activation time ## Actual results: Setting: ``` An error: In procedure raise exception: Value out of range -2147483648 to< 2147483647: 2147483648 ``` Getting ``` Activation: Fri Feb 21 18:31:34 2025 Expiration: Thu Jan 16 12:03:18 1919 ``` ## Expected results: Set the date to the correct time. Get the correct timestamp for expiration/activation. Interestingly when I use `gnutls_x509_crt_print` the dates are correct: ``` Validity: Not Before: Fri Feb 21 18:31:34 UTC 2025 Not After: Sun Feb 21 18:31:34 UTC 2055 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/33 You're receiving 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 Mar 4 18:12:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 17:12:34 +0000 Subject: [gnutls-devel] Guile-GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/issues/33#note_2378770874 Yes there is scm_from/to_long. I tried changing to scm_to/from_int64 for all time_t values and everything works without issues. So that must have been the problem. It seems like i misinterpreted the error. It might not be a gnutls error but a guile error because it cant convert to the given type. From manual ``` When X represents an exact integer that fits into the indicated C type, return that integer. Else signal an error, either a ?wrong-type? error when X is not an exact integer, or an ?out-of-range? error when it doesn?t fit the given range. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/33#note_2378770874 You're receiving 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 Mar 4 18:58:36 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 17:58:36 +0000 Subject: [gnutls-devel] Guile-GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/issues/33#note_2378844018 Something like this? ```diff diff --git a/guile/src/core.c b/guile/src/core.c index dd13149..289a228 100644 --- a/guile/src/core.c +++ b/guile/src/core.c @@ -3351,7 +3351,7 @@ SCM_DEFINE (scm_gnutls_x509_certificate_activation_time, c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); c_time = gnutls_x509_crt_get_activation_time (c_cert); - return scm_from_int (c_time); + return scm_from_long (c_time); } #undef FUNC_NAME @@ -3368,7 +3368,7 @@ SCM_DEFINE (scm_gnutls_set_x509_certificate_activation_time, time_t c_time; c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); - c_time = scm_to_int (time); + c_time = scm_to_long (time); err = gnutls_x509_crt_set_activation_time (c_cert, c_time); if (EXPECT_FALSE (err)) @@ -3390,7 +3390,7 @@ SCM_DEFINE (scm_gnutls_x509_certificate_expiration_time, c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); c_time = gnutls_x509_crt_get_expiration_time (c_cert); - return scm_from_int (c_time); + return scm_from_long (c_time); } #undef FUNC_NAME @@ -3407,7 +3407,7 @@ SCM_DEFINE (scm_gnutls_set_x509_certificate_expiration_time, time_t c_time; c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); - c_time = scm_to_int (time); + c_time = scm_to_long (time); err = gnutls_x509_crt_set_expiration_time (c_cert, c_time); if (EXPECT_FALSE (err)) ``` How would this work on a 32bit system with/without 64bit time_t? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/33#note_2378844018 You're receiving 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 Mar 4 19:07:46 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 18:07:46 +0000 Subject: [gnutls-devel] Guile-GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#33) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/issues/33#note_2378858266 Looks better than before to me. I realize that there may be platforms where even long is 4 and time_t is 8. But for all platforms where sizeof(long) >= sizeof(time_t) I think your patch works well. Could you propose a merge request? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/33#note_2378858266 You're receiving 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 Mar 4 19:39:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 18:39:09 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) References: Message-ID: Dariqq created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/33 Project:Branches: Dariqq/guile:master to gnutls/guile:master Author: Dariqq Fixes https://gitlab.com/gnutls/guile/-/issues/33 and https://gitlab.com/gnutls/guile/-/issues/32. Replace `scm_to/from_int` with `scm_to/from_long` when dealing with `time_t` values. To test this one can use a time value past 2038 in `tests/x509-certificate-generation.scm` for expiration/activation date. Before guile would error on converting the integer to `int` type. Not sure if this is something to test , there might be some architectures where `long` might still be to small to hold all `time_t` values. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33 You're receiving 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 Mar 4 19:59:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 18:59:59 +0000 Subject: [gnutls-devel] GnuTLS | [Experimental] Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: All discussions on merge request !1938 were resolved by David Dudas https://gitlab.com/gnutls/gnutls/-/merge_requests/1938 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938 You're receiving 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 Mar 4 20:01:15 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 19:01:15 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2378951126 Looks good to me! Is it possible to write a self-test that would trigger the bug? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2378951126 You're receiving 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 Mar 4 21:10:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 20:10:20 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2379047862 Should it be a seperate test or part of an existing one? For the latter you could pick your favourite numbers `>= 2^31` or `< -2^31` here for activation/expiration ```diff diff --git a/guile/tests/x509-certificate-generation.scm b/guile/tests/x509-certificate-generation.scm index 449f7be..3c45d23 100644 --- a/guile/tests/x509-certificate-generation.scm +++ b/guile/tests/x509-certificate-generation.scm @@ -34,7 +34,7 @@ (cert-format x509-certificate-format/pem) (serial #vu8(1 2 3 4)) (activation 946702800) ; 2000-01-01 - (expiration 1893474000)) ; 2030-01-01 + (expiration 2272143600)) ; 2042-01-01 (set-x509-certificate-ca-status! cert #f) (set-x509-certificate-dn-by-oid! cert oid/x520-country-name "US") (set-x509-certificate-dn-by-oid! cert oid/x520-state-or-province-name "MA") ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2379047862 You're receiving 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 Mar 4 21:56:52 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 20:56:52 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Fix pipeline (!34) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/34 Project:Branches: jas/guile-gnutls:master to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/34 You're receiving 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 Mar 4 22:02:13 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 21:02:13 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Fix pipeline (!35) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/35 Project:Branches: jas/guile-gnutls:wip to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/35 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Mar 4 22:02:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 21:02:48 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Fix pipeline (!34) In-Reply-To: References: Message-ID: Merge request !34 was closed by Simon Josefsson Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/34 Project:Branches: jas/guile-gnutls:master to gnutls/guile:master Author: Simon Josefsson Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/34 You're receiving 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 Mar 5 00:56:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 04 Mar 2025 23:56:20 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Fix pipeline (!35) In-Reply-To: References: Message-ID: Merge request !35 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/35 Project:Branches: jas/guile-gnutls:wip to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/35 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 5 01:02:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:02:48 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2379407815 Oh, that was simple -- thanks for looking into it. Yes, please just change the value in the existing test, and it will serve as a time64 regression chcker too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2379407815 You're receiving 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 Mar 5 01:03:41 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:03:41 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Wip2 (!36) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/36 Project:Branches: jas/guile-gnutls:wip2 to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/36 You're receiving 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 Mar 5 01:09:13 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:09:13 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Wip2 (!36) In-Reply-To: References: Message-ID: Merge request !36 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/36 Project:Branches: jas/guile-gnutls:wip2 to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/36 You're receiving 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 Mar 5 01:17:36 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:17:36 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Make ChangeLog reproducible. (!37) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/37 Project:Branches: jas/guile-gnutls:wip3 to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/37 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 5 01:27:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:27:39 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Make ChangeLog reproducible. (!37) In-Reply-To: References: Message-ID: Merge request !37 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/37 Project:Branches: jas/guile-gnutls:wip3 to gnutls/guile:master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/37 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 5 01:39:54 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:39:54 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/issues/31#note_2379452528 I have fixed the MLKEM/MLDSA pk-algorithms now. The self-checks on ArchLinux (which has a modern GnuTLS) catched that fine. Can we fix the self-check so that it fails on the sign algorithms too? It is a good way to catch these in the future too. You are right that many sign algorithms are missing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31#note_2379452528 You're receiving 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 Mar 5 01:46:32 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 00:46:32 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Rehandshake handling (#24) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/issues/24#note_2379456982 I think guile-gnutls supports reauthentication, see the `guile/tests/reauth.scm` self-test which uses the `connection-flag/auto-reauth` flag for example. Does this resolve your issue? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/24#note_2379456982 You're receiving 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 Mar 5 10:09:36 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 09:09:36 +0000 Subject: [gnutls-devel] GnuTLS | Differences in certificate verification results (#1642) In-Reply-To: References: Message-ID: dulanshuangqiao commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1642#note_2379962791 I updated my gnutls to 3.8.9 and enabled -strict-x509 as you mentioned, and still got the wrong result (still Verified). I updated the description of this issue and provided the corresponding content. I look forward to your reply. @ZoltanFridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1642#note_2379962791 You're receiving 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 Mar 5 11:53:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 10:53:33 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) References: Message-ID: Dariqq created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/38 Project:Branches: Dariqq/guile:sign-algorithms to gnutls/guile:master Author: Dariqq Fixes https://gitlab.com/gnutls/guile/-/issues/31. This adds the remaining signing algorithms and ajust the test to error if gnutls lists an algorithm that is not in the bindings (similar to the pk-algorithms one). The list now matches gnutls 3.8.9. I took the liberty to reorder the list to match the enum declaration in gnutls.h and added the same empty lines to help organize the list. The enum list now contains 48 + 1 entries (for unknown). The enum goes from `0-49` but number `19` is missing. The `(sign-algorithm-list)` contains 48 elements. There are probably some issues with some of the algorithms only being available in very recent gnutls versions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 5 11:55:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 10:55:59 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/issues/31#note_2380218687 I added a merge request that adds all of the remaining ones and adds a similar error for sign algorithms as for pk-algorithms. There is probably an issue with some of them not being available in older gnutls version. Not sure what to do about that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31#note_2380218687 You're receiving 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 Mar 5 12:15:14 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 11:15:14 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380260074 I am also not sure about these tests ``` (unless (member (sign-algorithm->string sign-algorithm/ecdsa-secp256r1-sha256) (map (lambda (alg) (and alg (sign-algorithm->string alg))) all-algorithms)) (error "Not enough listed sign algorithms")) (unless (member (pk-algorithm->string pk-algorithm/ecdsa) (map pk-algorithm->string all-algorithms)) (error "Not enough listed pk algorithms")) ``` These only check for the presence of a single sign/pk algo instead of missing items? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380260074 You're receiving 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 Mar 5 12:39:02 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 11:39:02 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380304364 Replaced the 2 dates with 2 new ones past 2038 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380304364 You're receiving 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 Mar 5 12:39:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 11:39:04 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: All discussions on merge request !33 were resolved by Dariqq https://gitlab.com/gnutls/guile/-/merge_requests/33 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33 You're receiving 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 Mar 5 13:39:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 12:39:23 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380445696 Looks good! Please rebase to latest master where the pipeline should be working. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380445696 You're receiving 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 Mar 5 13:42:02 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 12:42:02 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380454483 Thank you! You need to add logic to configure.ac to detect the symbol, otherwise you'll get build failures when building with older GnuTLS. Compare the recently added MLKEM/MLDSA patch. I'm hoping the signature algorithm #ifdef magic works the same way, and just happen to work if you use the right symbols in configure.ac. The pipeline should detect this for you, it uses various versions of GnuTLS with ArchLinux having the latest one but we also have really old GnuTLS too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380454483 You're receiving 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 Mar 5 13:45:36 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 12:45:36 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380463289 I agree the list should be sorted the same way as latest gnutls.h, for consistency. I'm not sure how to deal with the missing 19 element, probably simplest to just hard code this magic in the self-test for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380463289 You're receiving 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 Mar 5 14:14:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 13:14:37 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380532134 This is not a problem for anything, just that there is a hole in the gnutls enum. . i was just trying to explain that everything should be complete now and why there is 1 less that the current max in gnutls) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380532134 You're receiving 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 Mar 5 14:18:16 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 13:18:16 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380541924 is there a way I can find out the oldest version of gnutls that you'd want to support , most of the algorithms are probably ok as they have been available in gnutls for 10years+ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380541924 You're receiving 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 Mar 5 16:09:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:09:05 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380815762 I just found e7ba70f6dd8d3fe96e90845cb5c25eb99bee0175 which reverted the addition of (some) of the algorithms once before already. Not sure if this still a problem? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380815762 You're receiving 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 Mar 5 16:28:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:28:59 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380863054 Interesting! I suppose we'll find out via the pipeline, it does build on trisquel 10... Maybe the problem was that the enums wasn't sorted correctly in the old patch? @vivien\_ do you recall what the problem was? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380863054 You're receiving 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 Mar 5 16:34:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:34:39 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380876685 I suspect you will need to support quite old releases. As a first step, try to make the pipeline green. Maybe the oldest system in the pipeline is Ubuntu 20.04 but I think we have to go back a bit further to be safe. Adding a Ubuntu 18.04 job may help to get better test coverage... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380876685 You're receiving 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 Mar 5 16:40:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:40:25 +0000 Subject: [gnutls-devel] Guile-GnuTLS | year 2038 problem in x509-certificate-*-time (#32) In-Reply-To: References: Message-ID: Issue was closed by Simon Josefsson with merge request !33 (https://gitlab.com/gnutls/guile/-/merge_requests/33) Issue #32: https://gitlab.com/gnutls/guile/-/issues/32 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/32 You're receiving 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 Mar 5 16:40:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:40:25 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Merge request !33 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/33 Project:Branches: Dariqq/guile:master to gnutls/guile:master Author: Dariqq -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33 You're receiving 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 Mar 5 16:40:26 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:40:26 +0000 Subject: [gnutls-devel] Guile-GnuTLS | 32bit time issues with gnutls_x509_crt_[get, set]-*-time (#33) In-Reply-To: References: Message-ID: Issue was closed by Simon Josefsson with merge request !33 (https://gitlab.com/gnutls/guile/-/merge_requests/33) Issue #33: https://gitlab.com/gnutls/guile/-/issues/33 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/33 You're receiving 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 Mar 5 16:43:42 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:43:42 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380897579 I added a check for MLDSA, you seen to assume for the pk check that if MLDSA44 is available the other ones are aswell. I adapted the same logic -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380897579 You're receiving 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 Mar 5 16:47:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 15:47:48 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380905821 Merged, thank you! Please add a NEWS entry next time :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2380905821 You're receiving 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 Mar 5 17:12:00 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:12:00 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Draft: More x509-certificate-functions (!39) References: Message-ID: Dariqq created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/39 Project:Branches: Dariqq/guile:x509-certificate-functions to gnutls/guile:master Author: Dariqq includes bindings to: - gnutls_x509_crt_get_dn_by_oid and gnutls_x509_crt_get_issuer_dn_by_oid : I chose to always set the raw_flag to 0 to get a string back. - gnutls_x509_crt_get_signature - gnutls_x509_crt_print: not sure how to test this? I added the oneline output of the test certificate, is this reliable? - gnutls_x509_crt_verify: Here I am the most unsure. Is my schemified name ok? How to handle multiple signers? If no flags what should be used for the c_flags? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39 You're receiving 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 Mar 5 17:26:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:26:38 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Vivien Kraus commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380986870 I had failures such as this: https://gitlab.com/vivien_/guile/-/jobs/4677710713 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2380986870 You're receiving 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 Mar 5 17:33:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:33:38 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Vivien Kraus started a new discussion on guile/tests/list-sign-algorithms.scm: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381001084 > (error "The ecdsa-sha256 signature algorithm should use \ > the sha256 hash algorithm")) > (let ((all-algorithms (sign-algorithm-list))) > + (for-each > + (lambda (algo) > + (unless algo > + (error "gnutls lists more sign-algorithms than what gnutls-guile enumerates."))) Maybe it would be desirable to deactivate this test by default, and only have it in gnutls-guile?s CI only? So, if gnutls adds a new algorithm, we will notice it, but it will not fail the test suite for all other users. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381001084 You're receiving 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 Mar 5 17:51:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:51:48 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381034202 That is #26 and #22! I don't think they are related to adding new signing algorithms. There is something that is flaky on Ubuntu 20.04 and Trisquel 10 that trigger that error sometimes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381034202 You're receiving 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 Mar 5 17:51:50 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:51:50 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Draft: More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2381034294 This test case is failing (in tests/x509-certificate-generation.scm). ```scm (x509-certificate-verify? cert cert) ``` Reason is that i changed the activation date into the future and thus the cert is not valid yet. probably not a good idea to add a timebomb in the test? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2381034294 You're receiving 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 Mar 5 17:55:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 16:55:10 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion on guile/tests/list-sign-algorithms.scm: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381039755 > (error "The ecdsa-sha256 signature algorithm should use \ > the sha256 hash algorithm")) > (let ((all-algorithms (sign-algorithm-list))) > + (for-each > + (lambda (algo) > + (unless algo > + (error "gnutls lists more sign-algorithms than what gnutls-guile enumerates."))) What would the gain be? Doesn't this code only trigger (like the pk code that caused me to add MLKEM/MLDSA for ArchLinux) if you are building a too old guile-gnutls with a modern GnuTLS? Then the proper response should be to get a newer guile-gnutls (or prod us into making releases). So I think it is serve some purpose. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381039755 You're receiving 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 Mar 5 18:01:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 17:01:51 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381051512 Sounds good. I think the logic has to be that if multiple symbols were added in the same GnuTLS release, it is okay to check for one of them only and to set the NO_ symbols for all of those symbols at the same time. I would still group these by algorithm, though, since sometimes distributions patch away things, but presumably anyone dropping MLDSA44 would drop MLDSA65 too. Btw, note that MLKEM768 and MLKEM1024 were added in different GnuTLS releases, so I think it has to be checked for separately. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381051512 You're receiving 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 Mar 5 18:06:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 17:06:09 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Vivien Kraus commented on a discussion on guile/tests/list-sign-algorithms.scm: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381058691 > (error "The ecdsa-sha256 signature algorithm should use \ > the sha256 hash algorithm")) > (let ((all-algorithms (sign-algorithm-list))) > + (for-each > + (lambda (algo) > + (unless algo > + (error "gnutls lists more sign-algorithms than what gnutls-guile enumerates."))) I personally dislike it when a project refuses to build if it detects one of its dependencies to be too new. This is not terribly disruptive so I don?t care much. (The actual reponse from users will most likely be to disable this test and move on.) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381058691 You're receiving 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 Mar 5 18:20:24 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 17:20:24 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Vivien Kraus commented on a discussion on guile/tests/list-sign-algorithms.scm: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381084476 > (error "The ecdsa-sha256 signature algorithm should use \ > the sha256 hash algorithm")) > (let ((all-algorithms (sign-algorithm-list))) > + (for-each > + (lambda (algo) > + (unless algo > + (error "gnutls lists more sign-algorithms than what gnutls-guile enumerates."))) Sorry I messed up the thread, please ignore. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381084476 You're receiving 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 Mar 5 18:21:54 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 17:21:54 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381086439 I cant find those in gnutls_sign_algorithm_t The one before MLDSA is EDDSA_ED448 which already has a check. Then there are the GOST-* ones which got added in 2018 and then PSS_RSAE-SHA* which are not new and dont have a check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2381086439 You're receiving 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 Mar 5 18:40:40 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 05 Mar 2025 17:40:40 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Draft: More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2381117822 i commented it out for now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2381117822 You're receiving 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 Mar 7 10:31:02 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 09:31:02 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2384782326 Maybe something like this? Not sure what to do if the `HAVE_CONFIG_H` is not defined. Cant really test if it works on 32bit with 64bit time_t. Presumably Id need to recompile everything with 64bit time and not just guile-gnutls/gnutls. Can this be tested on debian i386 somehow which should have 64bit time? ```diff diff --git a/configure.ac b/configure.ac index e09b967..738be68 100644 --- a/configure.ac +++ b/configure.ac @@ -126,6 +126,8 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])], gnu89_inline=yes, gnu89_inline=no) AC_MSG_RESULT($gnu89_inline) CFLAGS="$_gcc_cflags_save" +AC_CHECK_SIZEOF(time_t) + # Optional Guile functions. save_CFLAGS="$CFLAGS" save_LIBS="$LIBS" diff --git a/guile/src/core.c b/guile/src/core.c index 289a228..ff97e49 100644 --- a/guile/src/core.c +++ b/guile/src/core.c @@ -21,6 +21,16 @@ #ifdef HAVE_CONFIG_H # include +#if SIZEOF_TIME_T == 8 +#define scm_to_time_t scm_to_int64 +#define scm_from_time_t scm_from_int64 +#elif SIZEOF_TIME_T == 4 +#define scm_to_time_t scm_to_int32 +#define scm_from_time_t scm_from_int32 +#else +#error sizeof(time_t) is not 4 or 8. +#endif +/* What to do here? */ #endif #include @@ -3351,7 +3361,7 @@ SCM_DEFINE (scm_gnutls_x509_certificate_activation_time, c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); c_time = gnutls_x509_crt_get_activation_time (c_cert); - return scm_from_long (c_time); + return scm_from_time_t (c_time); } #undef FUNC_NAME @@ -3368,7 +3378,7 @@ SCM_DEFINE (scm_gnutls_set_x509_certificate_activation_time, time_t c_time; c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); - c_time = scm_to_long (time); + c_time = scm_to_time_t (time); err = gnutls_x509_crt_set_activation_time (c_cert, c_time); if (EXPECT_FALSE (err)) @@ -3390,7 +3400,7 @@ SCM_DEFINE (scm_gnutls_x509_certificate_expiration_time, c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); c_time = gnutls_x509_crt_get_expiration_time (c_cert); - return scm_from_long (c_time); + return scm_from_time_t (c_time); } #undef FUNC_NAME @@ -3407,7 +3417,7 @@ SCM_DEFINE (scm_gnutls_set_x509_certificate_expiration_time, time_t c_time; c_cert = scm_to_gnutls_x509_certificate (cert, 1, FUNC_NAME); - c_time = scm_to_long (time); + c_time = scm_to_time_t (time); err = gnutls_x509_crt_set_expiration_time (c_cert, c_time); if (EXPECT_FALSE (err)) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2384782326 You're receiving 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 Mar 7 12:37:28 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 11:37:28 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Segmentation fault in `scm_gnutls_session_record_port` (#34) References: Message-ID: Christopher Baines created an issue: https://gitlab.com/gnutls/guile/-/issues/34 ``` Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007ff91c721605 in scm_gnutls_session_record_port (session=0x7ff93c3bffa0, close=0x904) at core.c:1251 warning: 1251 core.c: No such file or directory [Current thread is 1 (Thread 0x7ff840ff96c0 (LWP 12362))] (gdb) bt #0 0x00007ff91c721605 in scm_gnutls_session_record_port (session=#, close=#) at core.c:1251 #1 0x00007ff94c7b373f in vm_regular_engine (thread=0x7ff93c2256c0) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/vm-engine.c:972 #2 0x00007ff94c7c1445 in scm_call_n (proc=, argv=, nargs=0) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/vm.c:1616 #3 0x00007ff94c726cde in scm_call_with_unblocked_asyncs (proc=#) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/async.c:406 #4 0x00007ff94c7b373f in vm_regular_engine (thread=0x7ff93c2256c0) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/vm-engine.c:972 #5 0x00007ff94c7c1445 in scm_call_n (proc=, argv=, nargs=0) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/vm.c:1616 #6 0x00007ff94c7ad2a3 in really_launch (d=0x7ff93c1fb6e0) at /tmp/guix-build-guile-next-3.0.10-0.5d3f561.drv-0/source/libguile/threads.c:781 ... #19 0x00007ff94c21d8a4 in start_thread () from /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libc.so.6 #20 0x00007ff94c2947b8 in clone3 () from /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libc.so.6 (gdb) frame 0 #0 0x00007ff91c721605 in scm_gnutls_session_record_port (session=#, close=#) at core.c:1251 1251 in core.c (gdb) info locals port = 0x0 c_session = 0x7ff81d0906f0 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/34 You're receiving 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 Mar 7 17:40:42 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 16:40:42 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Segmentation fault in `scm_gnutls_session_record_port` (#34) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/issues/34#note_2385643418 Thanks @cbaines -- This looks like #29 to me?! I think the code is actually simple to fix here. It is deferring a NULL pointer. Understand WHY that pointer is NULL seems to be the hard part. Are you able to reproduce this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/34#note_2385643418 You're receiving 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 Mar 7 17:49:22 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 16:49:22 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Segmentation fault in `scm_gnutls_session_record_port` (#34) In-Reply-To: References: Message-ID: Christopher Baines commented: https://gitlab.com/gnutls/guile/-/issues/34#note_2385655778 I think the key difference is #29 involves `read_from_session_record_port` and the segfault actually happens in Guile, whereas here this involves `scm_gnutls_session_record_port` and the segfault happens there inside guile-gnutls. Maybe there's a common cause or it's a single issue that can cause failures in different ways. I have tried (and so far failed) to write a small reproducer for #29, and I haven't tried for this specific yet, but as you say, this is clearer so maybe it's easier to reproduce. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/34#note_2385655778 You're receiving 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 Mar 7 17:49:27 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 16:49:27 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Segmentation fault in `scm_gnutls_session_record_port` (#34) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/issues/34#note_2385655925 Can you explore what gdb says for `gnutls_session_get_ptr (c_session)` in this situation? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/34#note_2385655925 You're receiving 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 Mar 7 17:52:50 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 16:52:50 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385662012 Having some 32-bit architecture in the CI/CD pipeline would be the best to get confidence in a fix here. Maybe it is possible to build a i386 build from a Debian amd64 image somehow? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385662012 You're receiving 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 Mar 7 17:54:03 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 16:54:03 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385663802 I think it is fine to just abort compilation if `time_t` is not 4 or 8. Even better than just silently accepting the situation, as I don't really understand how to support any non-4/8 case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385663802 You're receiving 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 Mar 7 20:08:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 19:08:05 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385850061 It won't compile anyway in that case because the `scm_to/from_time_t` symbols dont exist in libguile (maybe they should?) . Also is core.c the right place for the `#define`'s or is there a better place to put them? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385850061 You're receiving 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 Mar 7 20:14:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 19:14:33 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385857042 I am not deeply familiar with debian but it should be possible to install 32bit variants of the build dependencies (and/or use gcc -m32 as the c compiler) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2385857042 You're receiving 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 Mar 7 22:02:05 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 21:02:05 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq marked merge request !39 as ready -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39 You're receiving 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 Mar 7 22:01:47 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 07 Mar 2025 21:01:47 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Draft: More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2385976967 Have removed the `x509_certify` for now until I figure how to use it better. The rest is probably ready (apart from my minor question from the beginnig) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2385976967 You're receiving 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 Mar 8 02:54:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 08 Mar 2025 01:54:25 +0000 Subject: [gnutls-devel] GnuTLS | The incorrect UTC time value. (#1675) References: Message-ID: Qianxin Cheng created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1675 ## Description of problem: The RFC standard for X.509 CRL restricts the thisUpdate field to only two formats: UTCTime (YYMMDDHHMMSSZ) in ASN.1 representation and GeneralizedTime (YYYYMMDDHHMMSSZ). However, GnuTLS 3.7.11 accepts the thisUpdate field format as (YYYYMMDDHHZ), with a value like ("2017090721Z") in the CRL. ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_file_gn_time.der ## Actual results: CRL?This Update?????Issued: Wed Dec 31 23:59:59 UTC 1969 ## Expected results: The RFC standard for X.509 CRL restricts the thisUpdate field to only two formats: ASN.1 encoded UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ). Therefore, it should reject a CRL with a thisUpdate field in the format (YYYYMMDDHHZ), with a value like ("2017090721Z").[crl_file_gn_time.der](/uploads/dbe2c4200feb727100571c3392d1feb2/crl_file_gn_time.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1675 You're receiving 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 Mar 8 06:55:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 08 Mar 2025 05:55:18 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2386451974 @Dariqq wrote > Cant really test if it works on 32bit with 64bit time_t. Presumably Id need to recompile everything with 64bit time and not just guile-gnutls/gnutls. Can this be tested on debian i386 somehow which should have 64bit time? Debian i386 does not have and will not have 64bit time. (It was exempt from the recent t64 transition because Debian/i386 is kept for running old legacy binaries, which would be broken by 64bit time.) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2386451974 You're receiving 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 Mar 8 09:17:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 08 Mar 2025 08:17:08 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Use long when converting to/from time_t. (!33) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2386628192 makes sense. I didn't read far enough in the debian wiki. I am still not happy with my current solution to the problem because it assumes that a long is big enough for a time_t value which may or may not be right (at least better than int which it was before) The test got updated so it will fail if long and time_t cant handle 64 bit integers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/33#note_2386628192 You're receiving 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 Mar 8 11:34:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 08 Mar 2025 10:34:09 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Segmentation fault in `scm_gnutls_session_record_port` (#34) In-Reply-To: References: Message-ID: Christopher Baines commented: https://gitlab.com/gnutls/guile/-/issues/34#note_2386715256 I'm not sure how to do that, I did try `call gnutls_session_get_ptr (c_session)`, but that didn't work, perhaps because I'm a core file rather than a breakpoint on a running process. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/34#note_2386715256 You're receiving 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 Mar 8 14:28:15 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 08 Mar 2025 13:28:15 +0000 Subject: [gnutls-devel] libtasn1 | Tarball reproducibility bug (#54) References: Message-ID: Simon Josefsson created an issue: https://gitlab.com/gnutls/libtasn1/-/issues/54 Attempting to reproduce the v4.20.0 release tarballs a couple of weeks after the release builds fine: https://gitlab.com/gnutls/libtasn1/-/pipelines/1706399616 However they are different compared to the release tarball: 1. The help2man outputs contain current timestamp instead of the release timestamp: ``` ? ? -.TH ASN1CODING "1" "March 2025" "libtasn1 4.20.0" "User Commands" ? ? +.TH ASN1CODING "1" "February 2025" "libtasn1 4.20.0" "User Commands" ``` This happens for asn1Coding.1, asn1Decoding.1 and asn1Parser.1. I think the solution is to somehow cause help2man to use the mtime of NEWS as the timestamp source here. I can't find any parameter to set this, so maybe we need to do some post-processing of the generated files. 2. doc/version.texi (and consequently doc/stamp-vti and doc/libtasn1.info) contains current timestamp instead of release timestamp: ``` ? ? - at set UPDATED 8 March 2025 ? ? - at set UPDATED-MONTH March 2025 ? ? + at set UPDATED 1 February 2025 ? ? + at set UPDATED-MONTH February 2025 ``` This happens because the files are generated by `make all` which is before the mtime of NEWS is set to release time by `make dist`, and these files are never rebuilt because the current timestamp of the files is later than the then release time of NEWS. I think the solution is to rebuild stamp-vti, version.texi and libtasn1.info when mtime of NEWS has changed. We could also set the mtime of NEWS earlier, before `make dist` time, but I'm not sure that is a good idea. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/54 You're receiving 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 Mar 9 20:47:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 09 Mar 2025 19:47:38 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387295148 Thank you! Looks fairly good. Remaining issues to fix pipeline failures: https://gitlab.com/Dariqq/guile/-/jobs/9348197236 https://gitlab.com/Dariqq/guile/-/jobs/9348197236 ``` FAIL: tests/x509-certificates.scm ================================= WARNING: (guile-user): imported module (gnutls build tests) overrides core binding `uniform-vector-read!' `uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from `(rnrs io ports)' instead. uniform-vector-element-size is deprecated. Instead, treat the uniform vector as a bytevector. scm_uniform_vector_elements is deprecated. Use scm_array_handle_uniform_elements instead. scm_uniform_vector_writable_elements is deprecated. Use scm_array_handle_uniform_writable_elements instead. FAIL tests/x509-certificates.scm (exit status: 1) ``` https://gitlab.com/Dariqq/guile/-/jobs/9348197269 https://gitlab.com/Dariqq/guile/-/jobs/9348197263 https://gitlab.com/Dariqq/guile/-/jobs/9348197257 Run 'make indent' to fix indentation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387295148 You're receiving 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 Mar 9 20:49:49 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 09 Mar 2025 19:49:49 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2387295466 Please indent the code: https://gitlab.com/Dariqq/guile/-/jobs/9321098461 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2387295466 You're receiving 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 Mar 9 21:24:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 09 Mar 2025 20:24:10 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Wip (!40) References: Message-ID: Simon Josefsson created a merge request: https://gitlab.com/gnutls/guile/-/merge_requests/40 Branches: wip to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/40 You're receiving 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 Mar 9 21:28:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 09 Mar 2025 20:28:59 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Wip (!40) In-Reply-To: References: Message-ID: Merge request !40 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/40 Branches: wip to master Author: Simon Josefsson -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/40 You're receiving 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 Mar 10 03:13:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 02:13:04 +0000 Subject: [gnutls-devel] GnuTLS | Gnutls cannot parse the Country value encoded in UTF8String. (#1676) References: Message-ID: Qianxin Cheng created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1676 ## Description of problem: Hello Developer, I created a CRL file where the Country value in the issuer field is encoded in UTF8String, with the value 'US'. However, I am unable to successfully parse this Country value when processing the CRL. RFC5280 specifies that DirectoryString can be encoded either in PrintableString or UTF8String. ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_file.der ## Actual results: The issuer field is parsed as Issuer: OU=test, CN=test, O=test, L=test, ST=test, C=#0c025553. ## Expected results: The issuer field should be parsed as Issuer: OU=test, CN=test, O=test, L=test, ST=test, C=US.[crl_file.der](/uploads/0d76de603cea7216532e93b612d8f219/crl_file.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1676 You're receiving 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 Mar 10 04:18:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 03:18:08 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS handling of escape characters (#1677) References: Message-ID: Qianxin Cheng created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1677 ## Description of problem: Hello Developer? I have a CRL file, and the "O" field in its issuer section contains an escape character. The value of the "O" field is 'VeriSign\'. When I use GnuTLS to parse this CRL file, GnuTLS interprets the "O" field as 'VeriSign\'. However, when I open the CRL file as a .crl file, the "O" field in the issuer section shows as 'VeriSign'. Therefore, I suspect that the handling of the escape character '\' by GnuTLS may not be entirely reasonable. ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_file_.der ## Actual results: The issuer field is parsed as Issuer: OU=Class 3 Public Primary Certification Authority,CN=test,O=VeriSign\\,L=test,ST=test,C=US. ## Expected results: [crl_file_.der](/uploads/b674b4d460fac0bcdd1590920f6edf65/crl_file_.der)[crl_file_.crl](/uploads/d9bdeab38ac289b18339de7f1d4bcb4c/crl_file_.crl) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1677 You're receiving 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 Mar 10 10:49:46 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 09:49:46 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387844586 I made the formatter happy: It wants a line break for get_issuer_dn_by_oid but not the subject one which I am not a fan of. ```c X509_CERTIFICATE_DN_BY_OID_FUNCTION_BODY (gnutls_x509_crt_get_dn_by_oid); [...] X509_CERTIFICATE_DN_BY_OID_FUNCTION_BODY (gnutls_x509_crt_get_issuer_dn_by_oid); ``` The local git diff on X509_CERTIFICATE_DN_BY_OID_FUNCTION_BODY also does not look great because of the tabs for the \ on each line (but the formatter did not complain). The test failure on alma/rocky is interesting. The warning in the output is irrelevant to the failure. Some better diagnostics on what subtest is failing would be great. Currently each subtest returns either #t or #f which then gets AND'ed to the final test result so all information on the subtests is lost. In the failing test I added a check for the signature of the cert and the oneline print output. The only thing i can think of is that the print output may vary between gnutls versions. I removed the print test on a separate branch and it seems to be the issue as now it also passes on rocky/alma https://gitlab.com/Dariqq/guile/-/jobs/9358732456 https://gitlab.com/Dariqq/guile/-/jobs/9358732441 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387844586 You're receiving 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 Mar 10 10:54:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 09:54:10 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2387854910 Done, everything is now green (Except the macos builds). I don't have a news entry yet because it potentially cause a merge conflict with the other mr news. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38#note_2387854910 You're receiving 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 Mar 10 11:36:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 10:36:35 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387965050 Yeah, formatting can get ugly, but you can use the `/* *INDENT-OFF* */` and `/* *INDENT-ON* */` keywords to allow hand-written indentation. I usually just give up and let it be a bit ugly though. Hm, the pipeline in the merge request is still failing, did you push the final changes to the same branch that the merge request is for? Then it should show up as green here. I think the pipeline you link to is for another commit not in this merge request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387965050 You're receiving 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 Mar 10 11:39:39 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 10:39:39 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Simon Josefsson commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387976543 I now realize that you could make this a bit more indentation friendly and readable by instead having a C function that takes a function pointer, instead of a CPP macro. This is easier to debug, if anyone ever ends up in gdb for these functions. I'm just mentioning this, no need to fix it if you prefer to finalize this instead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2387976543 You're receiving 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 Mar 10 11:41:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 10:41:08 +0000 Subject: [gnutls-devel] Guile-GnuTLS | Add missing signing algorithms (!38) In-Reply-To: References: Message-ID: Merge request !38 was merged Merge request URL: https://gitlab.com/gnutls/guile/-/merge_requests/38 Project:Branches: Dariqq/guile:sign-algorithms to gnutls/guile:master Author: Dariqq -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/38 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Mar 10 11:41:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 10:41:08 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Issue was closed by Simon Josefsson with merge request !38 (https://gitlab.com/gnutls/guile/-/merge_requests/38) Issue #31: https://gitlab.com/gnutls/guile/-/issues/31 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31 You're receiving 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 Mar 10 11:43:40 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 10:43:40 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/guile/-/issues/31#note_2387989943 Thank you @Dariqq -- merged now, please suggest a NEWS entry (I think all new enums should be mentioned). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31#note_2387989943 You're receiving 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 Mar 10 15:22:00 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 14:22:00 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388490441 I pushed them now. Tested on a seperate branch to not pollute this mr with me figuring out why the test was failing. I was just following the convention (?) from the rest of the file where you have the same logic for the issuer and subject DN but with differently named accessors, X509_CERTIFICATE_DN_FUNCTION_BODY and X509_CERTIFICATE_DN_OID_FUNCTION_BODY -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388490441 You're receiving 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 Mar 10 15:40:52 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 14:40:52 +0000 Subject: [gnutls-devel] Guile-GnuTLS | gnutls-sign-algorithm-enum is missing a lot of values (#31) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/issues/31#note_2388543765 Thank you @jas. Maybe something like ```org ** Add missing members of gnutls_sign_algorithm_t ``` I am not sure how to format the list of all enums in a pretty way (should it be the schemified names or the original names?) Maybe this way? I took my list from above, double checked with my commit and grouped them a bit to not require 30 lines ``` rsa-sha224, dsa-sha224, dsa-sha256, dsa-sha384, dsa-sha512 ecdsa-sha1, ecdsa-sha224, ecdsa-sha256, ecdsa-sha384, ecdsa-sha512 ecdsa-sha3-224, ecdsa-sha3-256, ecdsa-sha3-384, ecdsa-sha3-512 dsa-sha3-224, dsa-sha3-256, dsa-sha3-384, dsa-sha3-512 rsa-sha3-224, rsa-sha3-256, rsa-sha3-384, rsa-sha3-512 rsa-raw, gost-94, gost-256, gost-512 mldsa44, mldsa65, mldsa87 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/issues/31#note_2388543765 You're receiving 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 Mar 10 15:46:41 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 14:46:41 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388562568 Also the print-format enum is missing from NEWS. I made the format optional and the default GNUTLS_CRT_PRINT_FULL, but it is configurable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388562568 You're receiving 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 Mar 10 18:20:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 17:20:12 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388899117 In my quest to easily verify self signed certs I just discovered `gnutls_x509_crt_check_issuer` which seems to do the job better than the `gnutls_x509_crt_verify` i considered earlier. But there are also other `gnutls_x509_crt_check_*` functions which might be useful to have available for basic checks for a certificate -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2388899117 You're receiving 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 Mar 10 20:54:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 10 Mar 2025 19:54:30 +0000 Subject: [gnutls-devel] Guile-GnuTLS | More x509-certificate-functions (!39) In-Reply-To: References: Message-ID: Dariqq commented on a discussion: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2389220039 I added a binding to gnutls_x509_crt_check_issuer. the check_hostname is already here, there is a check_hostname2 which allows for more control but I noticed that some gnutls_certificate_verify_flags advertised in the documentation are missing in guile-gnutls and I am lacking motivation to complete them as well and this will be enough for my use case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/guile/-/merge_requests/39#note_2389220039 You're receiving 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 Mar 11 11:27:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 10:27:23 +0000 Subject: [gnutls-devel] GnuTLS | kTLS: add a timeout funtionality to _gnutls_ktls_recv() (#1679) References: Message-ID: Franti?ek Kren?elok created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1679 Currently the kTLS-receive implementation doesn't support timeouts, this can be handled by using the GNUTLS_E_AGAIN e.g. ``` do { ret = gnutls_record_recv(session, ...); } while (ret == GNUTLS_E_AGAIN); ``` But we shouldn't count on this especially in code that has been written in the past. Additional the user should have control over this for asynchronous implementations. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1679 You're receiving 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 Mar 11 13:49:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 12:49:07 +0000 Subject: [gnutls-devel] GnuTLS | kTLS: add a timeout funtionality to _gnutls_ktls_recv() (#1679) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2390446269 Afaik the common pattern to implement a timeout handling is to set up a session as non-block (e.g., `GNUTLS_NONBLOCK`) and then monitor any events with `poll` or some other system provided facilities. Wouldn't that work in the KTLS case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2390446269 You're receiving 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 Mar 11 14:26:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 13:26:10 +0000 Subject: [gnutls-devel] GnuTLS | p11tool manpage is not in line with 'PKCS #11 URI Matching Guidelines' (#1680) References: Message-ID: Zolt?n Fridrich created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1680 p11tool manpage is written in a way that implies that only one Token is specified by URL, however, PKCS #11 URI allows matching rules (see https://datatracker.ietf.org/doc/html/rfc7512#section-2.5) that allows one URI to match multiple tokens. This should be reflected in p11tool manpage. Incorrect wording is present in multiple sections of manpage and whole manpage should be reviewed. Couple of picked examples and suggested improvements are below. Version-Release number of selected component (if applicable): gnutls-utils-3.6.14-7.el8_3.x86_64 Actual state: 1) Object listing --list-all List all available objects in a token. All objects available in the token will be listed. 2) Key generation --generate-privkey=string Generate private-public key pair of given type. Generates a private-public key pair in the specified token. Suggested improvement: 1a) Object listing --list-all List all available objects. All available objects will be listed. 1b) Object listing --list-all List all available objects in a tokens matching specified URI. All objects available in the tokens matching URI will be listed. 2) Key generation --generate-privkey=string Generate private-public key pair of given type. Generates a private-public key pair in the specified token. Provided URI must match single token. Additional info: In SYNOPSIS or DESCRIPTION section of manpage, it could be clarified that URI may match multiple tokens and for some operation URI matching single token should be provided. Sentence saying something like "For more details about URIs and matching rules see The PKCS #11 URI Scheme" could be added. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1680 You're receiving 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 Mar 11 14:46:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 13:46:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls with allowlisting doesn't allow enabling sigalgs with priority strings (#1681) References: Message-ID: Zolt?n Fridrich created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1681 a signature algorithm disabled through allowlisting (e.g. with crypto-policies) cannot be reenabled back with priority strings alone How reproducible: reliably Steps to Reproduce (you can find the full steps in the attached reproducer): 1. remove mentions of RSA-PSS-RSAE-SHA256 from gnutls config, e.g., using a `sign = -RSA-PSS-RSAE-SHA2-256` subpolicy 2. attempt a connection from a client to the server which both use `@SYSTEM:-SIGN-ALL:+SIGN-RSA-PSS-RSAE-SHA256` as a priority string Actual results: <4> HSK[0x55f399502800]: CERTIFICATE VERIFY (15) was received. Length 260[260], frag offset 0, frag length: 260, sequence: 0 <4> HSK[0x55f399502800]: Parsing certificate verify <4> HSK[0x55f399502800]: verifying TLS 1.3 handshake data using RSA-PSS-RSAE-SHA256 <3> ASSERT: pubkey.c[pubkey_verify_data]:2426 <3> ASSERT: pubkey.c[gnutls_pubkey_verify_data2]:1942 <3> ASSERT: tls13-sig.c[_gnutls13_handshake_verify_data]:128 <3> ASSERT: tls13/certificate_verify.c[_gnutls13_recv_certificate_verify]:131 <3> ASSERT: handshake-tls13.c[_gnutls13_handshake_client]:129 Fatal error: One of the involved algorithms has insufficient security level. <5> REC: Sending Alert[2|71] - Insufficient security Expected results: connections succeeds and uses RSA-PSS-RSAE-SHA256 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1681 You're receiving 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 Mar 11 14:48:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 13:48:07 +0000 Subject: [gnutls-devel] GnuTLS | kTLS: add a timeout funtionality to _gnutls_ktls_recv() (#1679) In-Reply-To: References: Message-ID: Franti?ek Kren?elok commented: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2390582557 kTLS as implemented in GnuTLS is non-block by default so we might want to control that as well -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2390582557 You're receiving 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 Mar 11 15:01:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 11 Mar 2025 14:01:37 +0000 Subject: [gnutls-devel] GnuTLS | gnutls certtool pkcs12 export doesn't let selecting a PRF (#1682) References: Message-ID: Zolt?n Fridrich created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1682 certtool --to-p12 always uses hmacWithSHA256 How reproducible: always Steps to Reproduce: 1. openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch 2. certtool --to-p12 --outder --p12-name localhost --load-certificate localhost.crt --load-privkey localhost.key --outfile p12 --password pass --hash SHA512 3. openssl pkcs12 -in p12 -info -nodes -noout -passin pass:pass Actual results: MAC: sha512, Iteration 600000 MAC length: 64, salt length: 8 PKCS7 Encrypted data: PBES2, PBKDF2, AES-128-CBC, Iteration 600000, PRF hmacWithSHA256 Certificate bag PKCS7 Data Shrouded Keybag: PBES2, PBKDF2, AES-128-CBC, Iteration 600000, PRF hmacWithSHA256 Expected results: MAC: sha512, Iteration 600000 MAC length: 64, salt length: 8 PKCS7 Encrypted data: PBES2, PBKDF2, AES-128-CBC, Iteration 600000, PRF hmacWithSHA512 Certificate bag PKCS7 Data Shrouded Keybag: PBES2, PBKDF2, AES-128-CBC, Iteration 600000, PRF hmacWithSHA512 Additional info: maybe the control doesn't have to be --hash int gnutls_pkcs12_bag_encrypt(gnutls_pkcs12_bag_t bag, const char * pass, unsigned int /gnutls_pkcs_encrypt_flags_t/ flags) doesn't have a readily available avenue to pass a choice of a PRF, so this might entail quite some work code reference: https://gitlab.com/gnutls/gnutls/-/blob/c87f5aa5fd5a807a4444e428063db3f8635d378d/lib/x509/pkcs7-crypt.c#L1579 wishlist-grade, as this should be workaroundable -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1682 You're receiving 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 Mar 13 07:20:42 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 13 Mar 2025 06:20:42 +0000 Subject: [gnutls-devel] GnuTLS | [Experimental] Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2394363388 @d-Dudas I guess we can merge this, though I would like to see at least some tests that exercise the ML-DSA signature algorithms. Could you add one? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2394363388 You're receiving 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 Mar 14 12:42:27 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Mar 2025 11:42:27 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) References: Message-ID: Hannes Reinecke created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 Project:Branches: hare1712/gnutls:psk-sha384 to gnutls/gnutls:master Author: Hannes Reinecke * lib/psk: Add gnutls_psk_allocate_{client,server}_credentials2 Add new functions gnutls_psk_allocate_client_credentials2() and gnutls_psk_allocate_server_credentials2() which allow to specify the hash algorithm for the PSK. Fixes: [#1385](https://gitlab.com/gnutls/gnutls/-/issues/1385) Signed-off-by: Hannes Reinecke ## 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/1939 You're receiving 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 Mar 14 15:33:23 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 14 Mar 2025 14:33:23 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2398075491 Weelll ... Nice try. Problem is that on the server side you just will be getting binder value, and you have to evaluate the binder value to figure out which hash algorithm you _should_ have initialized :-( So for the server we would have to have both binder hashes available in order to check which to use. Hmm. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2398075491 You're receiving 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 Mar 15 13:38:02 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 15 Mar 2025 12:38:02 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399131904 I've now modified gnutls_psk_allocate_server_credentials2() to accept GNUTLS_MAC_NONE as argument. If that is given both possible algorithms SHA384 and SHA256 are applied in server_recv_params() to check which binder algorithm is used. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399131904 You're receiving 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 Mar 16 01:14:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Mar 2025 00:14:33 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399262637 The approach looks good to me. I wish the logic in `lib/ext/pre_shared_key.c` were made to be more declarative rather than a trial and error. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399262637 You're receiving 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 Mar 16 01:14:33 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Mar 2025 00:14:33 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399262626 > prf = pskcred->binder_algo; > + if (prf) > + mac = GNUTLS_MAC_NONE; Do you mean `GNUTLS_MAC_UNKNOWN`, or `mac = prf->id`? -- Daiki Ueno started a new discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2399262633 > gnutls_memcmp(binder_value, binder_recvd.data, binder_recvd.size)) { > + if (mac == GNUTLS_MAC_SHA384) { > + mac = GNUTLS_MAC_SHA256; Setting the same value again? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 You're receiving 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 Mar 16 05:36:06 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 16 Mar 2025 04:36:06 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940 Project:Branches: dueno/gnutls:wip/dueno/remove-liboqs to gnutls/gnutls:master Author: Daiki Ueno * build: remove support for liboqs Fixes: #1649 ## 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/1940 You're receiving 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 Mar 17 01:08:30 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 17 Mar 2025 00:08:30 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 Project:Branches: dueno/gnutls:wip/dueno/nst-data to gnutls/gnutls:master Author: Daiki Ueno * tests: add basic tests for 0-RTT with gnutls-serv and gnutls-cli * cli: send early data only after session data is set Now that max_early_data_size is recorded as part of the stored resumption data, this needs to be read before attempting to send early data. * handshake: preserve max_early_data_size across resumption Previously, max_early_data_size negotiated as part of NewSessionTicket is reset after a resumption, leading to an error in sending early data since we changed the default max_early_data_size to 0 in commit 9a7ce5a74cbef069394f677c0c79af2c876546db. This records the value along with the stored session ticket data. * serv: fix detection of early data reception Upon success, gnutls_record_recv_early_data returns the amount of data received, so the application should treat positive numbers as an indication of early data reception. Fixes: #1667 ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 You're receiving 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 Mar 18 08:23:40 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 07:23:40 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402261931 > > if (_gnutls_mac_get_algo_len(prf) != binder_recvd.size || > gnutls_memcmp(binder_value, binder_recvd.data, binder_recvd.size)) { > + if (mac == GNUTLS_MAC_SHA384) { > + mac = GNUTLS_MAC_SHA256; Not the same. Switching to SHA256 and recheck. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402261931 You're receiving 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 Mar 18 08:23:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 07:23:10 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402261306 > uint8_t ipsk[MAX_HASH_SIZE]; > > prf = pskcred->binder_algo; > + if (prf) > + mac = GNUTLS_MAC_NONE; Well, that's bit non-obvious, and probably should be changed. I use the check 'mac == GNUTLS_MAC_SHA384' to trigger a re-check, so if an algorithm is set I need to specify 'mac = GNUTLS_MAC_NONE' to avoid rechecking. So yeah, that needs to be reworked. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402261306 You're receiving 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 Mar 18 08:27:32 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 07:27:32 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402267227 Yes, and that was my first attempt. But on the server side we have to accommodate for old clients (which will use SHA256 binder algorithms even for SHA384 PSKs) and for new clients (which will use SHA384 for both binder algorithm and PSK). So we have to allow for both binder algorithms. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402267227 You're receiving 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 Mar 18 08:43:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 07:43:25 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402286772 > uint8_t ipsk[MAX_HASH_SIZE]; > > prf = pskcred->binder_algo; > + if (prf) > + mac = GNUTLS_MAC_NONE; Reworked the selection mechanism and added documentation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402286772 You're receiving 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 Mar 18 08:44:41 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 07:44:41 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Hannes Reinecke commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402287865 Reworked the selection algorithm which should address your reviews. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2402287865 You're receiving 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 Mar 18 14:12:14 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 13:12:14 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS handling of escape characters (#1677) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1677#note_2402993105 [`fprintf(outfile, "\tIssuer: %s\n", issuer_name.data);`](https://gitlab.com/gnutls/gnutls/-/blob/0967bf88052d72ebcc086c04d97313df50d72c05/src/certtool.c?page=3#L2208) suggests the extra backslash is part of `issuer_name.data` and not an artifact of printing. Worth looking into further. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1677#note_2402993105 You're receiving 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 Mar 18 14:22:28 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 18 Mar 2025 13:22:28 +0000 Subject: [gnutls-devel] GnuTLS | Gnutls incorrectly handles the CRL Number field (#1684) References: Message-ID: One happy person created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1684 ## Description of problem: Hello Developer, I have a CRL file with a CRL number value of -36. According to RFC5280, the CRL number should be a non-negative integer, but Gnutls successfully printed this CRL without any errors. However, the value of the CRL Number is "dc", which is 220 in decimal. ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_file_test_.der ## Actual results: The Gnutls successfully printed this CRL, but the value of the CRL Number is "dc", which is 220 in decimal. ## Test Cases: [crl_file_test_.der](/uploads/03fc0407a2cc0bdc45cfad091eed963f/crl_file_test_.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1684 You're receiving 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 Mar 19 13:01:19 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 19 Mar 2025 12:01:19 +0000 Subject: [gnutls-devel] GnuTLS | global: call lc_init at startup (!1942) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1942 Project:Branches: dueno/gnutls:wip/dueno/lc-init to gnutls/gnutls:master Author: Daiki Ueno * global: call lc_init at startup When leancrypto is statically linked, their constructor will not be called and which prevents some low-level algorithms being functional. This adds a manual initialization with lc_init() at the startup of the GnuTLS library. Suggested-by: Stephan Mueller Signed-off-by: Daiki Ueno ## 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/1942 You're receiving 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 Mar 21 01:33:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Mar 2025 00:33:01 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943 Project:Branches: dueno/gnutls:wip/dueno/ci-pin-nettle3 to gnutls/gnutls:master Author: Daiki Ueno * .gitlab-ci.yml: use Nettle from release-3.10-fixes branch The current Nettle master branch (for 4.0 release) contains incompatible changes which GnuTLS hasn't yet accommodated. This sticks to the latest 3.10 branch to work that around. ## 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/1943 You're receiving 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 Mar 21 13:51:08 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Mar 2025 12:51:08 +0000 Subject: [gnutls-devel] GnuTLS | The GnuTLS cannot handle the authorityCertSerialNumber field in the AKI extension of the CRL (#1686) References: Message-ID: One happy person created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1686 ## Description of problem: Hello developer, I found in the GnuTLS documentation that GnuTLS supports the CRL Number and AKI extension fields in the CRL extension. However, when I print a CRL file containing the authorityCertSerialNumber field, GnuTLS does not display the value of the authorityCertSerialNumber. Is this a bug, or does GnuTLS only support the keyIdentifier field? ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_file_test_0.der ## Expected results: Successfully printed the authorityCertSerialNumber field.[crl_file_test_0.der](/uploads/5d03814c87fd9b910661696e31abaead/crl_file_test_0.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1686 You're receiving 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 Mar 21 14:45:38 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 21 Mar 2025 13:45:38 +0000 Subject: [gnutls-devel] GnuTLS | The GnuTLS cannot handle the authorityCertSerialNumber field in the AKI extension of the CRL (#1686) In-Reply-To: References: Message-ID: Issue was closed by One happy person Issue #1686: https://gitlab.com/gnutls/gnutls/-/issues/1686 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1686 You're receiving 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 Mar 24 08:11:40 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 07:11:40 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: 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/1943 You're receiving 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 Mar 24 13:27:14 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 12:27:14 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: Merge request !1943 was approved by Zolt?n Fridrich Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943 Project:Branches: dueno/gnutls:wip/dueno/ci-pin-nettle3 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Mar 24 13:27:41 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 12:27:41 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413169409 Fix looks good. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413169409 You're receiving 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 Mar 24 13:57:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 12:57:34 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413230488 Fix looks good, but this slipping past the tests suggests we have a coverage gap. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413230488 You're receiving 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 Mar 24 14:00:06 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 13:00:06 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: Merge request !1943 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943 Project:Branches: dueno/gnutls:wip/dueno/ci-pin-nettle3 to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943 You're receiving 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 Mar 24 14:01:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 13:01:35 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: use Nettle from release-3.10-fixes branch (!1943) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413240339 Thank you for the review; I agree, let's take a closer look after !1940. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1943#note_2413240339 You're receiving 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 Mar 24 22:38:18 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 21:38:18 +0000 Subject: [gnutls-devel] GnuTLS | global: call lc_init at startup (!1942) In-Reply-To: References: Message-ID: 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/1942 You're receiving 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 Mar 24 22:42:06 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 21:42:06 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: 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/1940 You're receiving 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 Mar 24 22:43:37 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 24 Mar 2025 21:43:37 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: 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/1941 You're receiving 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 Mar 25 01:00:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 00:00:20 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Kamaljit Singh commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2414447602 > > if (_gnutls_mac_get_algo_len(prf) != binder_recvd.size || > gnutls_memcmp(binder_value, binder_recvd.data, binder_recvd.size)) { > + if (mac == GNUTLS_MAC_SHA384) { > + mac = GNUTLS_MAC_SHA256; Compilation fails for server_recv_params(). Removed '{' at end of line 983 to fix it. Please update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2414447602 You're receiving 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 Mar 25 01:12:45 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 00:12:45 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 was reviewed by Kamaljit Singh -- Kamaljit Singh commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2414459159 I didn't find GNUTLS_MAC_NONE defined in gnutls.h/.h.in but adding this allowed compile to succeed. Was it already defined somewhere that I missed perhaps?
diff of gnutls.h.in diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index 3e286b2967a5..18daff35c303 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -327,6 +327,7 @@ typedef enum { * algorithms. */ typedef enum { + GNUTLS_MAC_NONE = 0, GNUTLS_MAC_UNKNOWN = 0, GNUTLS_MAC_NULL = 1,
-- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 You're receiving 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 Mar 25 13:47:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 12:47:48 +0000 Subject: [gnutls-devel] GnuTLS | Draft: serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Daiki Ueno marked merge request !1941 as draft -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 You're receiving 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 Mar 25 13:52:21 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 12:52:21 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Daiki Ueno marked merge request !1941 as ready -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 You're receiving 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 Mar 25 13:53:40 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 12:53:40 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2415519657 So it turned out that `max_early_data_size` is already recorded, but in the gnutls-cli code, it is not picked because `gnutls_record_send_early_data` is called before `gnutls_session_set_data`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2415519657 You're receiving 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 Mar 25 14:11:53 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 13:11:53 +0000 Subject: [gnutls-devel] GnuTLS | global: call lc_init at startup (!1942) In-Reply-To: References: Message-ID: Merge request !1942 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1942 Project:Branches: dueno/gnutls:wip/dueno/lc-init to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Mar 25 14:40:58 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 13:40:58 +0000 Subject: [gnutls-devel] GnuTLS | global: call lc_init at startup (!1942) In-Reply-To: References: Message-ID: Merge request !1942 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1942 Project:Branches: dueno/gnutls:wip/dueno/lc-init to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1942 You're receiving 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 Mar 25 15:23:09 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 14:23:09 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/libgnutls.map: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2415754700 > + local: > + *; > +} GNUTLS_3_7_7; ```suggestion:-7+0 GNUTLS_3_8_10 { global: gnutls_psk_allocate_client_credentials2; gnutls_psk_allocate_server_credentials2; local: *; } GNUTLS_3_8_6; ``` -- Daiki Ueno started a new discussion on lib/psk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2415754735 > + /* TLS 1.3 - Only SHA-256 and SHA-384 are allowed */ > + if (mac != GNUTLS_MAC_SHA256 && mac != GNUTLS_MAC_SHA384) > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); `*sc` is leaking here -- Daiki Ueno started a new discussion on lib/psk.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2415754749 > + */ > + if (mac != GNUTLS_MAC_SHA256 && mac != GNUTLS_MAC_SHA384 && > + mac != GNUTLS_MAC_NONE) I couldn't find `GNUTLS_MAC_NONE` definition, where did it come from? There is `GNUTLS_MAC_UNKNOWN` though. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939 You're receiving 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 Mar 25 16:36:21 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 15:36:21 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Zolt?n Fridrich commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2415965745 Looks fine, I don't see any mistakes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2415965745 You're receiving 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 Mar 25 16:36:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 15:36:44 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Merge request !1941 was approved by Zolt?n Fridrich Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 Project:Branches: dueno/gnutls:wip/dueno/nst-data to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Mar 25 19:23:17 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 18:23:17 +0000 Subject: [gnutls-devel] GnuTLS | relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' (#1687) References: Message-ID: Thomas Debesse created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1687 I build nettle 3.10.1 as a static library on arm64 on Debian 12 Bookworm. Then I attempt to link the D?mon engine against it, but I get that linkage error: ``` lib/libnettle.a(fat-arm64.o): in function `fat_init': nettle/nettle-3.10.1/fat-arm64.c:251:(.text.startup+0x154): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' defined in .text section in lib/libnettle.a(aes256-decrypt.o) /usr/bin/ld: nettle/nettle-3.10.1/fat-arm64.c:251: warning: too many GOT entries for -fpic, please recompile with -fPIC ``` I get the same linkage error with nettle 3.8.1 on arm64 on Debian 12 Bookworm: ``` lib/libnettle.a(fat-arm64.o): in function `fat_init': nettle/nettle-3.8.1/fat-arm64.c:219:(.text.startup+0x154): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' defined in .text section in lib/libnettle.a(aes256-decrypt.o) /usr/bin/ld: nettle/nettle-3.8.1/fat-arm64.c:219: warning: too many GOT entries for -fpic, please recompile with -fPIC ``` But I know I don't get this error with nettle 3.8.1 when cross-compiling to arm64 on Debian 10 Buster (the cross-compiler is running on amd64). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1687 You're receiving 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 Mar 25 19:43:19 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 18:43:19 +0000 Subject: [gnutls-devel] GnuTLS | relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' (#1687) In-Reply-To: References: Message-ID: Thomas Debesse commented: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416333847 I get a similar error from other source file if I use `--disable-fat`: ``` lib/libnettle.a(buffer-init.o): in function `nettle_buffer_init': nettle-3.10.1/buffer-init.c:47:(.text+0x8): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `nettle_realloc' defined in .text section in lib/libnettle.a(realloc.o) /usr/bin/ld: nettle-3.10.1/buffer-init.c:47: warning: too many GOT entries for -fpic, please recompile with -fPIC ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416333847 You're receiving 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 Mar 25 22:59:20 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 21:59:20 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2416642285 Thanks for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941#note_2416642285 You're receiving 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 Mar 25 23:18:59 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 25 Mar 2025 22:18:59 +0000 Subject: [gnutls-devel] GnuTLS | serv: fix detection of early data reception (!1941) In-Reply-To: References: Message-ID: Merge request !1941 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 Project:Branches: dueno/gnutls:wip/dueno/nst-data to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1941 You're receiving 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 Mar 26 02:01:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 01:01:12 +0000 Subject: [gnutls-devel] GnuTLS | lib/psk: Add gnutls_psk_allocate_{client, server}_credentials2 (!1939) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/libgnutls.map: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2416759032 > *; > } GNUTLS_3_8_4; > > +GNUTLS_3_9_10 > +{ > + global: > + gnutls_psk_allocate_client_credentials2; > + gnutls_psk_allocate_server_credentials2; > + local: > + *; > +} GNUTLS_3_7_7; Also note, when adding a new API function, ABI check would fail; this should be suppressed by modifying `devel/libgnutls.abignore`, as described in https://gitlab.com/gnutls/gnutls/-/blob/master/CONTRIBUTING.md?ref_type=heads&plain=1#L172 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1939#note_2416759032 You're receiving 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 Mar 26 02:03:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 01:03:44 +0000 Subject: [gnutls-devel] GnuTLS | relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' (#1687) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416760299 As it seems the [D?mon game engine](https://github.com/DaemonEngine/Daemon) is using Nettle directly (not through GnuTLS), shouldn't it be reported to the Nettle [mailing list](https://lists.lysator.liu.se/mailman/postorius/lists/nettle-bugs.lists.lysator.liu.se/) instead? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416760299 You're receiving 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 Mar 26 04:30:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 03:30:25 +0000 Subject: [gnutls-devel] GnuTLS | relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' (#1687) In-Reply-To: References: Message-ID: Issue was closed by Thomas Debesse Issue #1687: https://gitlab.com/gnutls/gnutls/-/issues/1687 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1687 You're receiving 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 Mar 26 04:30:25 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 03:30:25 +0000 Subject: [gnutls-devel] GnuTLS | relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `_nettle_aes256_decrypt_c' (#1687) In-Reply-To: References: Message-ID: Thomas Debesse commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416842128 Hmm, sorry I followed links from https://github.com/gnutls/nettle to https://www.gnutls.org to there and didn't notice in the process it wasn't about nettle anymore. ?? Thank you for your answer! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1687#note_2416842128 You're receiving 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 Mar 26 06:38:51 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 05:38:51 +0000 Subject: [gnutls-devel] GnuTLS | [Experimental] Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2416922559 The test looks nice. Could you rebase so the CI should be fixed now? Also it would be nice to mention this change in NEWS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2416922559 You're receiving 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 Mar 26 07:01:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 06:01:48 +0000 Subject: [gnutls-devel] GnuTLS | Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Merge request !1938 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938 Project:Branches: d-Dudas/gnutls:ddudas/enable-tls-mldsa to gnutls/gnutls:master Author: David Dudas Assignees: Reviewers: -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 26 09:50:50 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 08:50:50 +0000 Subject: [gnutls-devel] GnuTLS | Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2417177239 Looks like the tlsfuzzer failures are persistent; could you take a look, or @tomato42 do you have any ideas? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2417177239 You're receiving 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 Mar 26 10:22:24 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 09:22:24 +0000 Subject: [gnutls-devel] GnuTLS | Enable MLDSA at TLS 1.3 level (!1938) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply) commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2417247456 This is the failure: ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1938#note_2417247456 You're receiving 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 Mar 26 12:49:15 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 11:49:15 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: Merge request !1940 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940 Project:Branches: dueno/gnutls:wip/dueno/remove-liboqs to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Mar 26 12:49:07 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 11:49:07 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940#note_2417580922 devel/dlwrap/oqs.syms might've been overlooked, LGTM otherwise -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940#note_2417580922 You're receiving 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 Mar 26 23:12:35 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 22:12:35 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940#note_2418790217 Thanks; removed the oqs.syms file and rebased. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940#note_2418790217 You're receiving 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 Mar 26 23:12:43 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 22:12:43 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: Merge request !1940 was set to auto-merge by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940 Project:Branches: dueno/gnutls:wip/dueno/remove-liboqs to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Mar 27 00:20:11 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 26 Mar 2025 23:20:11 +0000 Subject: [gnutls-devel] GnuTLS | build: remove support for liboqs (!1940) In-Reply-To: References: Message-ID: Merge request !1940 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940 Project:Branches: dueno/gnutls:wip/dueno/remove-liboqs to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Alexander Sosedkin and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1940 You're receiving 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 Mar 27 02:57:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Mar 2025 01:57:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC 5280 compliance: generalTime parser accepts value without seconds field (#1688) References: Message-ID: One happy person created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1688 ## Description of problem: The RFC standard for X.509 CRLs restricts the thisUpdate field to only two formats, namely UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ) in ASN.1 representation, which are 13 and 15 characters wide, respectively. However, GnuTLS 3.8.9 accepts CRL with a thisUpdate field of length 13 ("240123000000Z"). ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) certtool --crl-info --inder --infile crl_file_13gn.der ## Actual results: Issued: Wed Dec 31 23:59:59 UTC 1969 ## Expected results: The RFC standard for X.509 CRLs limits the thisUpdate field to only two formats: UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ) in ASN.1 encoding, which are 13 and 15 characters wide, respectively. Therefore, it should reject a CRL file with a thisUpdate field length of 13 ("240123000000Z"). [crl_file_13gn.der](/uploads/38f2662a26c87d4b6d9ae78350aed2cb/crl_file_13gn.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1688 You're receiving 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 Mar 27 15:57:01 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 27 Mar 2025 14:57:01 +0000 Subject: [gnutls-devel] GnuTLS | tests/privkey-keygen.c: expect MLDSA approved in FIPS mode (!1944) References: Message-ID: Alexander Sosedkin created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944 Project:Branches: asosedkin/gnutls:privkey-keygen-fails-in-fips to gnutls/gnutls:master Author: Alexander Sosedkin I don't see a CI job exercising leancrypto and FIPS, and I think I've already caught one one FIPS+leancrypto-specific regression. Fix for said regression: * tests/privkey-keygen.c: expect MLDSA to be approved in FIPS mode CI job for leancrypto and FIPS: * .gitlab-ci.yml: enable building/testing with leancrypto in FIPS mode ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [x] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944 You're receiving 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 Mar 28 07:04:12 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 06:04:12 +0000 Subject: [gnutls-devel] GnuTLS | test leancrypto+FIPS in CI + tests/privkey-keygen.c: expect MLDSA approved in FIPS mode (!1944) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2421583933 I'm actually not sure if we should mark ML-DSA approved at this stage, for 2 reasons: one is the incomplete public key validation and the other is no CAST for ML-DSA; we probably add some in `lib/crypto-selftests-pk.c`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2421583933 You're receiving 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 Mar 28 07:07:10 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 06:07:10 +0000 Subject: [gnutls-devel] GnuTLS | Add CAST for ML-DSA (#1689) References: Message-ID: Daiki Ueno created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1689 According to FIPS 140-3 IG [10.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf), cryptographic algorithm self-test is required for ML-DSA to be approved. We should have some in `lib/crypto-selftests-pk.c`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1689 You're receiving 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 Mar 28 08:16:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 07:16:04 +0000 Subject: [gnutls-devel] GnuTLS | kTLS: add a timeout funtionality to _gnutls_ktls_recv() (#1679) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1679: https://gitlab.com/gnutls/gnutls/-/issues/1679 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1679 You're receiving 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 Mar 28 08:16:04 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 07:16:04 +0000 Subject: [gnutls-devel] GnuTLS | kTLS: add a timeout funtionality to _gnutls_ktls_recv() (#1679) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2421687772 Let's close this issue now; afaik gnutls-serv/gnutls-cli are already written in that way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1679#note_2421687772 You're receiving 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 Mar 28 15:53:46 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 14:53:46 +0000 Subject: [gnutls-devel] GnuTLS | Draft: test leancrypto+FIPS in CI + tests/privkey-keygen.c: expect MLDSA approved in FIPS mode (!1944) In-Reply-To: References: Message-ID: Alexander Sosedkin marked merge request !1944 as draft -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944 You're receiving 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 Mar 28 15:54:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 14:54:44 +0000 Subject: [gnutls-devel] GnuTLS | Draft: test leancrypto+FIPS in CI + tests/privkey-keygen.c: expect MLDSA approved in FIPS mode (!1944) In-Reply-To: References: Message-ID: Alexander Sosedkin commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2422608857 OK. Should we mark it unapproved in the meantime? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2422608857 You're receiving 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 Mar 29 00:41:34 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 28 Mar 2025 23:41:34 +0000 Subject: [gnutls-devel] GnuTLS | Draft: test leancrypto+FIPS in CI + tests/privkey-keygen.c: expect MLDSA approved in FIPS mode (!1944) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2423468643 I think that's safer, yes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1944#note_2423468643 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: