From gnutls-devel at lists.gnutls.org Wed May 1 06:46:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 04:46:44 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: @tomato42 This issue is unlabelled after 30 days. It needs attention. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_165792386 You're receiving 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 May 1 06:46:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 04:46:43 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: @akichangy This issue is unlabelled after 30 days. It needs attention. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735#note_165792385 You're receiving 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 May 1 06:46:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 04:46:43 +0000 Subject: [gnutls-devel] GnuTLS | Consider dropping heartbeat support (#743) In-Reply-To: References: Message-ID: @nmav This issue is unlabelled after 30 days. It needs attention. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/743#note_165792376 You're receiving 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 May 1 06:46:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 04:46:43 +0000 Subject: [gnutls-devel] GnuTLS | Run tlsfuzzer against gnutls built with clang asan and ubsan (#741) In-Reply-To: References: Message-ID: @tomato42 This issue is unlabelled after 30 days. It needs attention. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/741#note_165792382 You're receiving 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 May 1 06:46:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 04:46:42 +0000 Subject: [gnutls-devel] GnuTLS | Issues require labels (#760) References: Message-ID: New Issue was created. Issue 760: https://gitlab.com/gnutls/gnutls/issues/760 Author: GnuTLS bot Assignee: The following issues require labels: - [ ] [Consider dropping heartbeat support](https://gitlab.com/gnutls/gnutls/issues/743) - [ ] [Run tlsfuzzer against gnutls built with clang asan and ubsan](https://gitlab.com/gnutls/gnutls/issues/741) - [ ] [Unwanted -lunistring leak to global LIBS in configure](https://gitlab.com/gnutls/gnutls/issues/735) - [ ] [multiple issues in handling KeyUpdate messages](https://gitlab.com/gnutls/gnutls/issues/699) Please take care of them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/760 You're receiving 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 May 1 07:29:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 05:29:44 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: OBATA Akio commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/735#note_165797204 I have no way to add labels. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735#note_165797204 You're receiving 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 May 1 08:36:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 06:36:07 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: All discussions on Merge Request !988 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/988 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988 You're receiving 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 May 1 08:36:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 06:36:09 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_165806044 > } > } > > +/** > + * _gnutls_cipher_get_iv: > + * @handle: is a #gnutls_cipher_hd_t type > + * @iv: the IV to set > + * @ivlen: the length of the IV > + * > + * This function will get the IV to be used for the next encryption Indeed, I made this public and expanded the documentation to cover non-CFB cases. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_165806044 You're receiving 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 May 1 19:55:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 17:55:56 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Thanks, but looking at it again, it seems that ciphers can also be registered externally by the application using `gnutls_crypto_register_cipher` and even internally we register ciphers using `gnutls_crypto_single_cipher_register` in `lib/accelerated`. In these ciphers the `get_iv` pointer will not be set. I'm not sure what's the best approach here. Maybe we should prohibit this API for anything else than CFB (which is only internally defined), and also prohibit registering CFB when the `get_iv` is not set. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_165928917 You're receiving 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 May 1 20:00:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 18:00:27 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735 You're receiving 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 May 1 20:00:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 18:00:47 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: Thanks for following up. It seems it fell through the cracks. Would you like to open an MR to address that? This will significantly improve the chances for including the fix in 3.6.8. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735#note_165929659 You're receiving 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 May 1 20:05:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 18:05:41 +0000 Subject: [gnutls-devel] GnuTLS | Run tlsfuzzer against gnutls built with clang asan and ubsan (#741) In-Reply-To: References: Message-ID: There are two requests here: - run full test suite with clang (possibly on linux as on freebsd not all necessary tools are present) - run full test suite with ubsan (makes sense to me and probably easy to fix) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/741#note_165930452 You're receiving 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 May 1 20:14:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 18:14:10 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: `lib/minitasn1` are files copied from libtasn1 so should not be updated. `lib/nettle` are gnutls files related to nettle so we can update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_165932128 You're receiving 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 May 1 20:39:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 18:39:27 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/987 was reviewed by Nikos Mavrogiannopoulos -- Nikos Mavrogiannopoulos started a new discussion on lib/auth.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_165946553 > bool allow_tls13 = 0; > unsigned key_usage; > + const gnutls_sign_algorithm_t *sign_algos = gnutls_sign_list(); this is not a thread safe function to call here. I just checked its documentation and it does not seem to mention that fact. -- Nikos Mavrogiannopoulos started a new discussion on lib/auth.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_165946554 > - break; > + /* check if the private key is usable for signing in TLS 1.3 */ > + if (session->security_parameters.entity == GNUTLS_SERVER) { While that is generic and correct, isn't it an overkill to do for all private keys, and iterate over all signature algorithms? Isn't the problematic case we want to catch, related to RSA private keys? If yes, then what if we only check for them with a fixed RSA-PSS signature? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 1 21:13:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 01 May 2019 19:13:44 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: This pull request **fixes 37 alerts** when merging 3d02a841c1bc9b6b32c0ad5e2ff7fdb436429132 into 1ee821191870e425b2e645476b5c311dddb66938 - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-75ac2ca2d457c559198abe15268719892984784d) **fixed alerts:** * 37 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_165951788 You're receiving 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 May 2 11:03:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 09:03:32 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: In that case I would rather move the function back to internal and make it work only with nettle ciphers, at least for now, because: - the final IV can be actually calculated from the ciphertext and the initial IV input (= `IV[0..s*i] C[s*i..b]`) - that means the only real use-case is for validation (e.g., FIPS) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166076212 You're receiving 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 May 2 11:47:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 09:47:58 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/auth.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_166099829 > gnutls_certificate_credentials_t c = cred; > - unsigned i; > + unsigned i, j; > bool allow_tls13 = 0; > unsigned key_usage; > + const gnutls_sign_algorithm_t *sign_algos = gnutls_sign_list(); > + const gnutls_sign_entry_st *se; > > if (c != NULL && c->ncerts != 0) { > for (i = 0; i < c->ncerts; i++) { > key_usage = get_key_usage(session, c->certs[i].cert_list[0].pubkey); > if (key_usage == 0 || (key_usage & GNUTLS_KEY_DIGITAL_SIGNATURE)) { > - allow_tls13 = 1; > - break; > + /* check if the private key is usable for signing in TLS 1.3 */ > + if (session->security_parameters.entity == GNUTLS_SERVER) { I think we nevertheless would need to check all the signature algorithms, for the case where ECDSA/EdDSA keys are available but RSA-PSS is not usable. I'm moving the iteration logic into `lib/algorithms/sign.c` so it doesn't have thread-safety issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_166099829 You're receiving 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 May 2 13:18:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 11:18:59 +0000 Subject: [gnutls-devel] GnuTLS | Updated asm files to latest version under cryptogams license (!989) References: Message-ID: New Merge Request !989 https://gitlab.com/gnutls/gnutls/merge_requests/989 Project:Branches: nmav/gnutls:tmp-asm to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignee: This updates the openssl submodule as well as the asm files generated by it, to the latest stable version. ## 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) ## 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/989 You're receiving 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 May 2 13:25:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 11:25:19 +0000 Subject: [gnutls-devel] GnuTLS | Updated asm files to latest version under cryptogams license (!989) In-Reply-To: References: Message-ID: Performance comparison (on a cpu without `sha_ni`): NEW code: ``` Testing throughput in cipher/MAC combinations (payload: 16384 bytes) AES-128-GCM - TLS1.2 1.79 GB/sec AES-128-GCM - TLS1.3 1.43 GB/sec AES-128-CCM - TLS1.2 0.28 GB/sec AES-128-CCM - TLS1.3 0.29 GB/sec CHACHA20-POLY1305 - TLS1.2 0.21 GB/sec CHACHA20-POLY1305 - TLS1.3 0.21 GB/sec AES-128-CBC - TLS1.0 0.28 GB/sec ``` Old code: ``` Testing throughput in cipher/MAC combinations (payload: 16384 bytes) AES-128-GCM - TLS1.2 1.75 GB/sec AES-128-GCM - TLS1.3 1.43 GB/sec AES-128-CCM - TLS1.2 0.30 GB/sec AES-128-CCM - TLS1.3 0.28 GB/sec CHACHA20-POLY1305 - TLS1.2 0.21 GB/sec CHACHA20-POLY1305 - TLS1.3 0.21 GB/sec AES-128-CBC - TLS1.0 0.25 GB/sec ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/989#note_166137160 You're receiving 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 May 2 16:21:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 14:21:48 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Makes sense to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166205930 You're receiving 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 May 2 16:22:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 14:22:57 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: In that case, do we need it to be included to gnutls? Can't we include it in the acvp driver? @smuellerDD? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166206412 You're receiving 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 May 2 16:35:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 14:35:17 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Hi Nikos, > In that case, do we need it to be included to gnutls? Can't we include it in > the acvp driver? @smuellerDD? The code for getting the IV can surely be added to the ACVP driver. But how do you propose that should work? We started the discussion on adding the IV gathering function to GnuTLS because the IV is held so deep inside the cipher handle data structure that a calling application would have hard time to find the right location in the cipher handle. What about the following: let us have the gnutls_cipher_get_iv function inside the GnuTLS code that is NOT an exported API. Yet, the function is not marked as static or otherwise private. This would allow a wrapping application to still call it. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166211770 You're receiving 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 May 2 17:00:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 15:00:41 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Is this internal IV subject to validation? Wouldn't it be feasible to do something like (not tested at all though): ```c gnutls_cipher_init(&ch, GNUTLS_CIPHER_AES_128_CFB8, &key, &iv); gnutls_cipher_encrypt(ch, data.data, data.size); block_size = gnutls_cipher_get_block_size(GNUTLS_CIPHER_AES_128_CFB8); if (data.size < block_size) { /* concatenate the initial IV and ciphertext */ memcpy(next_iv, iv.data + block_size - (block_size - data.size), block_size - data.size); memcpy(next_iv + block_size - data.size, data.data, block_size - (block_size - data.size)); } else { /* use the last block of the ciphertext */ memcpy(next_iv, data.data + (data.size - block_size), block_size); } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166222618 You're receiving 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 May 2 17:07:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 15:07:39 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add API to retrieve the final IV for CFB ciphers (!988) In-Reply-To: References: Message-ID: Hi Daiki, > Is this internal IV subject to validation? Yes, I need the IV after an encrypt or decrypt operation. > Wouldn't it be feasible to do > something like (not tested at all though): > ```c > gnutls_cipher_init(&ch, GNUTLS_CIPHER_AES_128_CFB8, &key, &iv); > gnutls_cipher_encrypt(ch, data.data, data.size); > block_size = gnutls_cipher_get_block_size(GNUTLS_CIPHER_AES_128_CFB8); > if (data.size < block_size) { > /* concatenate the initial IV and ciphertext */ > memcpy(next_iv, iv.data + block_size - (block_size - data.size), > block_size - data.size); memcpy(next_iv + block_size - data.size, > data.data, block_size - (block_size - data.size)); } else { > /* use the last block of the ciphertext */ > memcpy(next_iv, data.data + (data.size - block_size), block_size); > } > ``` It seems that you are proposing to re-create the IV operation GnuTLS applies in the calling code. This is not permissible. We need the IV that was left by GnuTLS' operation. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166225271 You're receiving 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 May 3 01:46:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 02 May 2019 23:46:36 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fastopen: only use connectx if available (!876) In-Reply-To: References: Message-ID: Merge Request !876 was closed by S?bastien Blin Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/876 Project:Branches: AmarOk1412/gnutls:fix/connectx to gnutls/gnutls:master Author: S?bastien Blin Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/876 You're receiving 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 May 3 06:04:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 04:04:40 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) References: Message-ID: New Issue was created. Issue 761: https://gitlab.com/gnutls/gnutls/issues/761 Author: Itay Grudev Assignee: ## Description of problem: I believe the `_gnutls_srp_entry_free` function has a bug in it's implementation. There is a safety feature for accidental freeing of the SRP parameters defined in `gnutls.h` but those don't include the `8192` group values. https://gitlab.com/gnutls/gnutls/blob/master/lib/auth/srp_passwd.c#L445 And those values are different and need to be added there: https://gitlab.com/gnutls/gnutls/blob/master/lib/auth/srp_kx.c#L672 ## Version of gnutls used: master -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761 You're receiving 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 May 3 11:11:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 09:11:05 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: OK, thank you for the clarification. I've reverted the previous change so that you can use the private function `_gnutls_cipher_get_iv()` for that purpose. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166467314 You're receiving 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 May 3 11:12:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 09:12:30 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Hi Daiki, > * 9781cfe7 - crypto: add private API to retrieve internal IV If I read the code right, the ACVP application would need to call _gnutls_cipher_get_iv? If so, we are good. Note, there is no need to add the IV gathering to the self tests. But it does not hurt either :-) Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166467722 You're receiving 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 May 3 15:57:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 13:57:38 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166581295 > If I read the code right, the ACVP application would need to call _gnutls_cipher_get_iv? Yes. > Note, there is no need to add the IV gathering to the self tests. But it does not hurt either :-) I added those self tests just because I couldn't find appropriate place in the regular tests. Perhaps it might make sense to create a new test for them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166581295 You're receiving 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 May 3 19:01:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:01:51 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) In-Reply-To: References: Message-ID: Thank you for reporting this. Do you have a reproducer for the issue? Would you like to send an MR with the fix? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761#note_166639446 You're receiving 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 May 3 19:02:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:02:01 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761 You're receiving 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 May 3 19:10:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:10:15 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Reassigned Merge Request 988 https://gitlab.com/gnutls/gnutls/merge_requests/988 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988 You're receiving 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 May 3 19:10:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:10:51 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Merge Request !988 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/988 Branches: tmp-getiv to master Author: Daiki Ueno Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988 You're receiving 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 May 3 19:11:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:11:02 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Merge Request !988 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/988 Branches: tmp-getiv to master Author: Daiki Ueno Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988 You're receiving 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 May 3 19:11:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 17:11:01 +0000 Subject: [gnutls-devel] GnuTLS | crypto: add private API to retrieve internal IV (!988) In-Reply-To: References: Message-ID: Thank you. Merged manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/988#note_166641567 You're receiving 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 May 3 23:40:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 21:40:12 +0000 Subject: [gnutls-devel] GnuTLS | DH keys tests (!990) References: Message-ID: New Merge Request !990 https://gitlab.com/gnutls/gnutls/merge_requests/990 Project:Branches: simo5/gnutls:ec-dh-keys-tests to gnutls/gnutls:master Author: Simo Sorce Assignee: Add a test required by FIPS certification. ## 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 ## 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/990 You're receiving 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 May 3 23:43:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 03 May 2019 21:43:25 +0000 Subject: [gnutls-devel] GnuTLS | DH keys tests (!990) In-Reply-To: References: Message-ID: I haven't found a test where DH is exercised directly, only indirectly via TLS negotiations. Should we add a test for this change ? It is pretty straightforward. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_166710594 You're receiving 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 May 4 02:58:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 04 May 2019 00:58:47 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) In-Reply-To: References: Message-ID: Sure. I'll submit a PR the moment I have some free time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761#note_166727626 You're receiving 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 May 4 16:37:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 04 May 2019 14:37:26 +0000 Subject: [gnutls-devel] GnuTLS | DH keys tests (!990) In-Reply-To: References: Message-ID: I think the only testing was part of the cavs testing which is not part of the test suite. For that testing we introduced `_gnutls_dh_compute_key` and `_gnutls_dh_generate_key` which can also be used for an internal test suite and it would be a good idea to have for the negative cases to ensure we reject parameters which we are supposed to. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_166779101 You're receiving 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 May 4 16:40:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 04 May 2019 14:40:16 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: While the test is straight forward it makes me feel a little uneasy that it is run on every session initiated by the server. Although the cost is not high in terms of RSA cost, but as we are going to faster primitives such additional checks on every session will eventually be seen. What about running the test when we add a key in the credentials structure? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_166779329 You're receiving 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 May 4 22:35:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 04 May 2019 20:35:01 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: @nmav ping :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_166807180 You're receiving 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 May 5 16:54:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 05 May 2019 14:54:16 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) References: Message-ID: New Merge Request !991 https://gitlab.com/gnutls/gnutls/merge_requests/991 Project:Branches: JohnAZoidberg/gnutls:fix-guile-option to gnutls/gnutls:master Author: Daniel Schaefer Assignee: Without the square brackets autoconf turns hyphens into underscores (e.g. `__with_guile_site_dir=`), which is not what we want or what the help and manual say. See: https://www.gnu.org/software/autoconf/manual/autoconf.html#External-Software ## 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/991 You're receiving 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 May 6 13:51:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 11:51:57 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/954 was reviewed by Nikos Mavrogiannopoulos -- Nikos Mavrogiannopoulos started a new discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066352 > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) That seems unrelated change. What's the purpose of it? -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066356 > */ > > - I do not think we should change any values used by API headers. Any definitions there are part of the API -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/compat.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066358 > /* Typedefs for more compatibility with older GnuTLS. */ > > -#ifndef _GNUTLS_COMPAT_H Same as for gnutls.h.in -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutlsxx.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066361 > */ > > -#ifndef GNUTLSXX_H same as for gnutls.h.in -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/pkcs11.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066365 > */ > > -#ifndef __GNUTLS_PKCS11_H same as for gnutls.h.in -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/self-test.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066370 > */ > > -#ifndef __GNUTLS_SELF_H Same as for gnutls.h.in -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/system-keys.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066375 > */ > > -#ifndef __GNUTLS_SYSTEM_KEYS_H same as for all exported headers -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/tpm.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066378 > */ > > -#ifndef __GNUTLS_TPM_H same here for exported headers -- Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/urls.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066381 > */ > > -#ifndef __GNUTLS_URLS_H same here for exported headers -- Nikos Mavrogiannopoulos started a new discussion on lib/auth/srp_passwd.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167066385 > */ > > +#ifndef GNUTLS_LIB_AUTH_SRP_PASSWD_H Seeing this aren't we way too verbose with that rule? Is there a reason to have the GNUTLS prefix in files which are not exposed to applications? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954 You're receiving 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 May 6 19:37:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 17:37:24 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167222157 > > AM_CONDITIONAL(NEEDS_LIBRT, test "$gnutls_needs_librt" = "yes") > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) Please see above: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_164949593 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167222157 You're receiving 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 May 6 19:42:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 17:42:33 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/includes/gnutls/pkcs11.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167223261 > * > */ > > -#ifndef __GNUTLS_PKCS11_H Starting defines (and other non function-local names) with _ is reserved for C implementation. The earlier we straighten this the better. I know it (obviously) works for now, but I saw the first static analyzers being picky about it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167223261 You're receiving 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 May 6 19:47:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 17:47:08 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/auth/srp_passwd.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167225487 > * > */ > > +#ifndef GNUTLS_LIB_AUTH_SRP_PASSWD_H The more verbose the better. It's all about uniqueness and having a simple rule (so we can generate header guard names with a small algorithm in the future). So having long names is not bad in this case - it's a good thing. If we start making exemptions we would need a list about what and why. I am against that - it easily ends up where we are now: wild mixture of funny naming. And nobody wants to maintain such a list of exemptions, I guess. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167225487 You're receiving 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 May 6 19:50:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 17:50:51 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/includes/gnutls/gnutls.h.in: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167226318 > * The low level cipher functionality is in gnutls/crypto.h. > */ > > - That's a good reason not to change anything in `lib/includes/gnutls/` - but please consider my other comment about leading _. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167226318 You're receiving 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 May 6 20:04:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 06 May 2019 18:04:33 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) In-Reply-To: References: Message-ID: Please make sure: CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) And then restart the failed jobs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/991#note_167229299 You're receiving 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 May 7 12:55:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 10:55:31 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167460277 > > AM_CONDITIONAL(NEEDS_LIBRT, test "$gnutls_needs_librt" = "yes") > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) Let's remove it if it is unnecessary. I do not remember anything about it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167460277 You're receiving 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 May 7 12:57:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 10:57:40 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/pkcs11.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167461096 > * > */ > > -#ifndef __GNUTLS_PKCS11_H I agree, we have a milestone for 3.7.0 which may include API changes. We can create a ticket and assign it to that milestone to avoid breaking a stable release. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167461096 You're receiving 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 May 7 12:59:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 10:59:15 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/srp_passwd.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167461623 > * > */ > > +#ifndef GNUTLS_LIB_AUTH_SRP_PASSWD_H I was not referring to exceptions (the `lib/includes/` directory is an exception anyway as it contains exported files). However, for the internal header guards do we need the `GNUTLS_` prefix? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167461623 You're receiving 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 May 7 13:15:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 11:15:31 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/auth/srp_passwd.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167469721 > * > */ > > +#ifndef GNUTLS_LIB_AUTH_SRP_PASSWD_H Yes. To be one the save side, the project name should be part of the header guard even for internal files. We are not talking about strings that have to be typed somewhere - just about a world-unique string to avoid clashes. Of course we could debate at what point a string is considered world-unique and if we could make it shorter in any means. But what for ? Neither file size nor CPU utilization (when building) is affected. Of course we could also use a SHA(1/2/3) hash as header guard... but what I found when searching was a repeating hint for header guard (also internal): project name + relative path/filename (+ file extension). I also will enforce this rule for other projects like libidn2, wget and wget2/libwget. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167469721 You're receiving 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 May 7 13:51:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 11:51:07 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) References: Message-ID: New Merge Request !992 https://gitlab.com/gnutls/gnutls/merge_requests/992 Project:Branches: GostCrypt/gnutls:fix-streebog to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignees: Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [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/992 You're receiving 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 May 7 15:05:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 13:05:33 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/nettle/gost/streebog.c: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167527141 > } > } > > + cf = 0; > ctx->sigma[0] += M[0]; > for (i = 1; i < 8; i++) > - if (ctx->sigma[i-1] < M[i-1]) > - ctx->sigma[i] += M[i] + 1; > - else > - ctx->sigma[i] += M[i]; > + { > + if (ctx->sigma[i-1] != M[i-1]) > + cf = (ctx->sigma[i-1] < M[i-1]); Is it correct that `cf` never gets back to 0 once it has been set ? Somehow seems wrong... it would 0x00000001 + 0x000000FF would result in 0x01010100 instead of 0x00000100. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167527141 You're receiving 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 May 7 15:21:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 13:21:42 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/nettle/gost/streebog.c: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167534005 > } > } > > + cf = 0; > ctx->sigma[0] += M[0]; > for (i = 1; i < 8; i++) > - if (ctx->sigma[i-1] < M[i-1]) > - ctx->sigma[i] += M[i] + 1; > - else > - ctx->sigma[i] += M[i]; > + { > + if (ctx->sigma[i-1] != M[i-1]) > + cf = (ctx->sigma[i-1] < M[i-1]); No, it will be reset once there is no carried overflow. In your example (if we use bytes instead of u64, lsb arrays): sigma = 01 00 00 00 M = ff 00 00 00 0. sigma = **00** 00 00 00 1. i = 1, cf = 1, sigma = 00 **01** 00 00 2. i = 2, cf = 0, sigma = 00 01 **00** 00 3. i = 3, cf = 0, sigma = 00 01 00 **00** A failing example: sigma = ff ff ff 00 00 M = ff ff ff 00 00 then: 0. sigma = **fe** ff ff 00 00 1. i = 1, cf = 1 (overflow), sigma = fe **ff** ff 00 00 2. i = 2, cf = 1 (carried), sigma = fe ff **ff** 00 00 (with current code this would be fe ff **fe** 00 00) 3. i = 3, cf = 1 (carried), sigma = fe ff ff **01** 00 4. i = 4, cf = 0 (reset, no overflow), sigma = fe ff ff 01 **00** -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167534005 You're receiving 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 May 7 15:54:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 13:54:07 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/nettle/gost/streebog.c: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167553884 > } > } > > + cf = 0; > ctx->sigma[0] += M[0]; > for (i = 1; i < 8; i++) > - if (ctx->sigma[i-1] < M[i-1]) > - ctx->sigma[i] += M[i] + 1; > - else > - ctx->sigma[i] += M[i]; > + { > + if (ctx->sigma[i-1] != M[i-1]) > + cf = (ctx->sigma[i-1] < M[i-1]); Yes, you are right :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167553884 You're receiving 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 May 7 15:54:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 13:54:08 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: All discussions on Merge Request !992 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/992 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992 You're receiving 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 May 7 16:06:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 14:06:47 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Merge Request !992 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/992 Project:Branches: GostCrypt/gnutls:fix-streebog to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992 You're receiving 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 May 7 16:41:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 14:41:43 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Should we introduce a NEWS entry documenting the change? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167583331 You're receiving 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 May 7 16:43:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 14:43:27 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/srp_passwd.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167584110 > * > */ > > +#ifndef GNUTLS_LIB_AUTH_SRP_PASSWD_H Ok, no objection then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167584110 You're receiving 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 May 7 16:44:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 14:44:04 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: @nmav Something like 'fix calculation of Streebog digest'. I'd really like to push this code where it belongs - to Nettle library. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167584364 You're receiving 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 May 7 16:44:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 14:44:57 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/pkcs11.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167584805 > * > */ > > -#ifndef __GNUTLS_PKCS11_H My recommendation would be to revert the exported headers changes, and postpone them for a later release which we can more comfortably do minor API tweaks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167584805 You're receiving 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 May 7 17:59:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 15:59:31 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Sounds good to me. Yes, having it in nettle would be great! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_167620472 You're receiving 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 May 7 19:28:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 17:28:12 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Merge Request !985 was approved by Hubert Kario (@mention me if you need reply) Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/985 Branches: tmp-record-sizes to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985 You're receiving 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 May 7 19:28:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 17:28:31 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: r+ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_167647188 You're receiving 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 May 7 21:14:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:14:52 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/includes/gnutls/ (!993) References: Message-ID: New Merge Request !993 https://gitlab.com/gnutls/gnutls/merge_requests/993 Branches: tmp-public-header-guards to master Author: Tim R?hsen Assignees: Fixing the public header guards following the contribution guide amended in !954 ## 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) * [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/993 You're receiving 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 May 7 21:16:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:16:29 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672323 > > AM_CONDITIONAL(NEEDS_LIBRT, test "$gnutls_needs_librt" = "yes") > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) Move this (the whole public header guard commit) to !993 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672323 You're receiving 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 May 7 21:17:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:17:14 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/includes/gnutls/gnutls.h.in: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672467 > * The low level cipher functionality is in gnutls/crypto.h. > */ > > - In !993 with Milestone set to 3.7.0 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672467 You're receiving 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 May 7 21:18:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:18:05 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/includes/gnutls/pkcs11.h: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672633 > * > */ > > -#ifndef __GNUTLS_PKCS11_H See !993 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167672633 You're receiving 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 May 7 21:18:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:18:18 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: All discussions on Merge Request !954 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/954 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954 You're receiving 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 May 7 21:50:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 19:50:31 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: This pull request **fixes 37 alerts** when merging d726c955344bbcda9b17c5b5f17785a68f0870b9 into 03e1f6430150ef19d432e56d334b0f1d2424aeaa - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-c4f79ab9ae478afc4b40fa35b2d3bf6ba3af1b27) **fixed alerts:** * 37 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167680983 You're receiving 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 May 8 01:25:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 07 May 2019 23:25:51 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) In-Reply-To: References: Message-ID: Alright, pipelines have passed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/991#note_167717354 You're receiving 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 May 8 06:00:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 04:00:19 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/includes/gnutls/ (!993) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/993#note_167748900 > > AM_CONDITIONAL(NEEDS_LIBRT, test "$gnutls_needs_librt" = "yes") > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) I think that's fine to simply delete that line. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/993#note_167748900 You're receiving 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 May 8 06:03:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 04:03:54 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Merge Request !954 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/954 Branches: tmp-header-guards to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954 You're receiving 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 May 8 06:04:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 04:04:42 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: LGTM. The closes #738 seem incorrect though. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167749339 You're receiving 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 May 8 06:04:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 04:04:49 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Reassigned Merge Request 954 https://gitlab.com/gnutls/gnutls/merge_requests/954 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954 You're receiving 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 May 8 09:27:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 07:27:21 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Changed to closes #728 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954#note_167797186 You're receiving 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 May 8 09:45:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 07:45:53 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/includes/gnutls/ (!993) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/993#note_167803522 > > AM_CONDITIONAL(NEEDS_LIBRT, test "$gnutls_needs_librt" = "yes") > > -AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) > +#AC_DEFINE([GNUTLS_COMPAT_H], 1, [Make sure we don't use old features in code.]) Done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/993#note_167803522 You're receiving 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 May 8 09:45:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 07:45:53 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/includes/gnutls/ (!993) In-Reply-To: References: Message-ID: All discussions on Merge Request !993 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/993 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/993 You're receiving 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 May 8 09:46:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 07:46:42 +0000 Subject: [gnutls-devel] GnuTLS | Consistent header guards (#728) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #728: https://gitlab.com/gnutls/gnutls/issues/728 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/728 You're receiving 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 May 8 09:46:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 07:46:43 +0000 Subject: [gnutls-devel] GnuTLS | Add or clean header guards in lib/ (!954) In-Reply-To: References: Message-ID: Merge Request !954 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/954 Branches: tmp-header-guards to master Author: Tim R?hsen Assignee: Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/954 You're receiving 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 May 8 14:29:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 12:29:11 +0000 Subject: [gnutls-devel] GnuTLS | Should we check each argument of public gnutls functions to prevent crashes ? (#763) References: Message-ID: New Issue was created. Issue 763: https://gitlab.com/gnutls/gnutls/issues/763 Author: Tim R?hsen Assignees: In GnuTLS public functions, sometimes arguments are checked (e.g. pointers against NULL), sometimes not. Is there a general rule/policy for this ? If not, does it make sense to check against invalid values to prevent crashes (and thus hard-to-reproduce reports) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/763 You're receiving 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 May 8 21:09:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 19:09:22 +0000 Subject: [gnutls-devel] GnuTLS | Should we check each argument of public gnutls functions to prevent crashes ? (#763) In-Reply-To: References: Message-ID: I do not think that there is or was no policy for it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/763#note_168059448 You're receiving 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 May 8 21:53:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 19:53:41 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) References: Message-ID: New Merge Request !994 https://gitlab.com/gnutls/gnutls/merge_requests/994 Branches: tmp-lgtm-suppress-ctime to master Author: Nikos Mavrogiannopoulos Assignees: This suppresses some unnecessary errors by lgtm. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature ## Reviewer's checklist: * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994 You're receiving 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 May 8 22:50:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 20:50:51 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: This pull request **fixes 5 alerts** when merging 2d06c7e90f6cc66b4ec6a3076c428b7dd919c01d into 664fc06c44301eb811a28b444f35dd8e3c688dea - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-14c93e34648c21153563b90838fde025c0b4a4f3) **fixed alerts:** * 5 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168080761 You're receiving 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 May 8 22:57:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 08 May 2019 20:57:17 +0000 Subject: [gnutls-devel] GnuTLS | Should we check each argument of public gnutls functions to prevent crashes ? (#763) In-Reply-To: References: Message-ID: Then let's reduce it to NULL value checks. I agree that it might be overwhelming to even address that for all gnutls functions. But in the long term, this might reduce maintenance: now a NULL pointer access that crashes an application within the library code will come up as issue "GnuTLS crashes at ...". With a proper check and an appropriate error return would make the application developer check his code before opening an issue against GnuTLS. Suggestion: We can simply make a table of lib/ files in this issue and slowly check each one. Nothing that has to be done within one day or one single MR. Whenever one file (all the functions) has been checked, we flag that file's table entry. If you don't agree, please just close this issue. I'm also fine with keeping things as is. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/763#note_168082088 You're receiving 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 May 9 05:10:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 03:10:53 +0000 Subject: [gnutls-devel] GnuTLS | Test failure in test-ciphers-api.sh (#764) References: Message-ID: New Issue was created. Issue 764: https://gitlab.com/gnutls/gnutls/issues/764 Author: Ricardo M_ Correia Assignees: ## Description of problem: I am getting `FAIL: test-ciphers-api.sh` when running tests on aarch64. ## Version of gnutls used: 3.6.7 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) NixOS ## How reproducible: 100%. Steps to Reproduce: * Try to build gnutls on NixOS on an aarch64 machine. ## Actual results: A bunch of assertion failures like these: ``` FAIL: test-ciphers-api.sh ========================= trying aes128-gcm cipher-api-test: gcm.c:429: nettle_gcm_update: Assertion `ctx->auth_size % GCM_BLOCK_SIZE == 0' failed. cipher-api-test: gcm.c:479: nettle_gcm_encrypt: Assertion `ctx->data_size % GCM_BLOCK_SIZE == 0' failed. trying aes256-gcm cipher-api-test: gcm.c:429: nettle_gcm_update: Assertion `ctx->auth_size % GCM_BLOCK_SIZE == 0' failed. cipher-api-test: gcm.c:479: nettle_gcm_encrypt: Assertion `ctx->data_size % GCM_BLOCK_SIZE == 0' failed. trying aes128-cbc cipher-api-test: cbc.c:53: nettle_cbc_encrypt: Assertion `!(length % block_size)' failed. trying aes256-cbc cipher-api-test: cbc.c:53: nettle_cbc_encrypt: Assertion `!(length % block_size)' failed. (...) check_status:206: Child died with signal 4 SSSE3 cipher tests failed FAIL test-ciphers-api.sh (exit status: 1) ============================================================================ Testsuite summary for GnuTLS 3.6.7 ============================================================================ # TOTAL: 6 # PASS: 5 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/slow/test-suite.log Please report to bugs at gnutls.org ============================================================================ make[4]: *** [Makefile:1975: test-suite.log] Error 1 make[4]: Leaving directory '/build/gnutls-3.6.7/tests/slow' ``` ## Expected results: No test failure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/764 You're receiving 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 May 9 05:14:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 03:14:31 +0000 Subject: [gnutls-devel] GnuTLS | Test failure in test-ciphers-api.sh (#764) In-Reply-To: References: Message-ID: AFAICT, the issue is that `cipher-api-test.c` expects that assertion failures in nettle cause a `SIGABRT` signal to be raised, while on my machine the `SIGILL` signal is raised instead. The following patch seems to fix the issue for me: [aarch64-test-fix.patch](/uploads/a1b830e03ff31a79bf2a20bca6947607/aarch64-test-fix.patch) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/764#note_168158230 You're receiving 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 May 9 08:29:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 06:29:54 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: This pull request **fixes 5 alerts** when merging 30205fed83c1ab0b8cb62fa114baf7145af5f16c into 664fc06c44301eb811a28b444f35dd8e3c688dea - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-6bd2c3910c53d6aeda231af75320507971ba628b) **fixed alerts:** * 5 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168186320 You're receiving 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 May 9 09:55:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 07:55:03 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on src/certtool.c: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168214561 > > if (ca_crt && (secs > gnutls_x509_crt_get_expiration_time(ca_crt))) { > time_t exp = gnutls_x509_crt_get_expiration_time(ca_crt); > - fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); > - fprintf(stderr, "CA expiration time: %s", ctime(&exp)); > + fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); //lgtm [cpp/potentially-dangerous-function] I am against adding suppressions for a single static analyzer service like LGTM in the source code. Consequently you also have to add suppressions for all the other static analyzers out there, which blows up code and make it unreadable. As an exception I would agree to suppressions for gcc+clang as they are basic tools that we likely use forever. Services like LGTM come and go. In this case I would even throw in that ctime() indeed should be avoided. Just think of copy&pasting code into a multi-threaded application or library. After an RCE, someone will ask "where did this code come from ? Oh from GnuTLS - what a crap !". Working around ctime() will also silence *any* static analyzer. In this case ctime_r() seems appropriate. But it doesn't provide a buffer length (the docs say the buffer has to be 26 bytes at least - but what if you are above year 9999 ?). So in the end (if locale support is needed), a small helper using strftime() sems to be the best solution. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168214561 You're receiving 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 May 9 10:20:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 08:20:05 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: All discussions on Merge Request !985 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/985 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985 You're receiving 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 May 9 10:21:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 08:21:43 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: @tomato42 thank you for the review. @nmav, could you take a quick look at this before landing? It touches many places where record limits are handled. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168223868 You're receiving 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 May 9 10:50:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 08:50:00 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) In-Reply-To: References: Message-ID: Merge Request !991 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/991 Project:Branches: JohnAZoidberg/gnutls:fix-guile-option to gnutls/gnutls:master Author: Daniel Schaefer Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/991 You're receiving 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 May 9 10:50:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 08:50:28 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) In-Reply-To: References: Message-ID: Merge Request !991 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/991 Project:Branches: JohnAZoidberg/gnutls:fix-guile-option to gnutls/gnutls:master Author: Daniel Schaefer Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/991 You're receiving 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 May 9 10:50:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 08:50:37 +0000 Subject: [gnutls-devel] GnuTLS | guile: Properly format guile configure options (!991) In-Reply-To: References: Message-ID: Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/991#note_168235424 You're receiving 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 May 9 21:34:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 19:34:46 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/certtool.c: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168475016 > > if (ca_crt && (secs > gnutls_x509_crt_get_expiration_time(ca_crt))) { > time_t exp = gnutls_x509_crt_get_expiration_time(ca_crt); > - fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); > - fprintf(stderr, "CA expiration time: %s", ctime(&exp)); > + fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); //lgtm [cpp/potentially-dangerous-function] > In this case I would even throw in that ctime() indeed should be avoided. Just think of copy&pasting code into a multi-threaded application or library. After an RCE, someone will ask "where did this code come from ? Oh from GnuTLS - what a crap !". `ctime()` is perfectly fine the way it is used in this application. I understand someone else can misuse it but I do not see much value in writing code for other applications than the one intended for. Anyway, I was convinced to make that warning go in general, so I've pushed for another version which uses strftime with '%c'. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168475016 You're receiving 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 May 9 21:37:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 19:37:40 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/libgnutls.map: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168475636 > gnutls_pcert_import_rawpk; > gnutls_pcert_import_rawpk_raw; > gnutls_prf_early; > + gnutls_record_set_max_recv_size; Shouldn't this be part of the 3_6_8 version? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168475636 You're receiving 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 May 9 21:43:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 19:43:27 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/max_record.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168476806 > - * doesn't have the limitation, as long as the value ranges between > - * 512 and 16384. Note that not all TLS implementations use or even > - * understand those extension. > + * called 'max fragment length', which limits the acceptable values to > + * 512(=2^9), 1024(=2^10), 2048(=2^11) and 4096(=2^12). > * > - * In TLS 1.3, the value is the length of plaintext content plus its > - * padding, excluding content type octet. > + * Since 3.6.4, the limit is also negotiated through a new TLS > + * extension called 'record size limit', which doesn't have the > + * limitation, as long as the value ranges between 512 and 16384. > + * Note that while the 'record size limit' extension is preferred, not > + * all TLS implementations use or even understand the extension. > + * > + * Deprecated: if the client can assume that the 'record size limit' > + * extension is supported by the server, it had better use I think "had" is a typo here. should sounds more natural, if I understand the meaning correctly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168476806 You're receiving 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 May 9 22:01:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:01:05 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/985 was reviewed by Nikos Mavrogiannopoulos -- Nikos Mavrogiannopoulos started a new discussion on lib/libgnutls.map: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480324 > gnutls_pcert_import_rawpk_raw; > gnutls_prf_early; > + gnutls_record_set_max_recv_size; Shouldn't this and `gnutls_prf_early` be on the 3_6_8 version? -- Nikos Mavrogiannopoulos started a new discussion on tests/tls-record-size-limit-asym.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480325 > + }, > + { > + .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.2", Any reason this shouldn't be tested under TLS1.3 (and the default version) as well? -- Nikos Mavrogiannopoulos started a new discussion on tests/tls-record-size-limit-asym.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480326 > + serverx509cred); > + > + gnutls_priority_set_direct(server, test->prio, NULL); This could fail if the priority string in the test is malformed. -- Nikos Mavrogiannopoulos started a new discussion on tests/tls-record-size-limit-asym.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480327 > + ret = gnutls_certificate_set_x509_trust_mem(clientx509cred, &ca2_cert, GNUTLS_X509_FMT_PEM); > + if (ret < 0) > + exit(1); using fail instead of exit will print the line number of the failure and that can be useful during debugging of an issue -- Nikos Mavrogiannopoulos started a new discussion on tests/tls-record-size-limit-asym.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480328 > + global_init(); > + > + /* General init. */ It may be a good idea to assign a name on the test and print here the name of the test started. Otherwise a failure will not be easy to pinpoint without following the test with a debugger. -- Nikos Mavrogiannopoulos started a new discussion on lib/ext/max_record.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480330 > + * > + * Deprecated: if the client can assume that the 'record size limit' > + * extension is supported by the server, it had better use I think the "had" should be "should" if I understand the meaning correctly. What if we say "We recommend to use `gnutls_record_set_max_recv_size()` in new applications. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985 You're receiving 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 May 9 22:02:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:02:14 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: > @nmav, could you take a quick look at this before landing? It touches many places where record limits are handled. I went through it but only did a superficial review (ignored logic) as I remember very little about the previous max record support. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168480544 You're receiving 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 May 9 22:04:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:04:49 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: from the list above (3) should already be addressed via !917, is that right @dueno ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_168481039 You're receiving 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 May 9 22:05:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:05:14 +0000 Subject: [gnutls-devel] GnuTLS | Issues require labels (#760) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #760: https://gitlab.com/gnutls/gnutls/issues/760 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/760 You're receiving 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 May 9 22:08:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:08:11 +0000 Subject: [gnutls-devel] GnuTLS | Test failure in test-ciphers-api.sh (#764) In-Reply-To: References: Message-ID: `SIGILL` is however the wrong signal. To my understanding it means that an illegal instruction was executed. Do you see other tests failing? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/764#note_168481606 You're receiving 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 May 9 22:09:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:09:10 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from jeevan.ginnie@gmail.com): issue of backward compatibility for so.26 and so.28 (#759) In-Reply-To: References: Message-ID: This is not an issue in the library. What you are dealing with are abi incompatible versions of the library. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/759#note_168481796 You're receiving 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 May 9 22:09:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:09:11 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from jeevan.ginnie@gmail.com): issue of backward compatibility for so.26 and so.28 (#759) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #759: https://gitlab.com/gnutls/gnutls/issues/759 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/759 You're receiving 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 May 9 22:14:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:14:19 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: This pull request **fixes 15 alerts** when merging da1681ab244ee9ffad820b8b61659f1ef9b66e6f into 9509af0e791b74538de8ffa8dd0d47c05cb08eed - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-3a39bddd293d4829e456b055c3b0edfcd06b3bd8) **fixed alerts:** * 10 for Use of potentially dangerous function * 5 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168482706 You're receiving 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 May 9 22:14:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 09 May 2019 20:14:21 +0000 Subject: [gnutls-devel] GnuTLS | Should we check each argument of public gnutls functions to prevent crashes ? (#763) In-Reply-To: References: Message-ID: I do not mind :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/763#note_168482710 You're receiving 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 May 10 05:58:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 03:58:59 +0000 Subject: [gnutls-devel] GnuTLS | Test failure in test-ciphers-api.sh (#764) In-Reply-To: References: Message-ID: No, all other tests pass. This test also passes if I apply the above patch. Furthermore, this issue is 100% reproducible for me. Could there be something weird going on with the signal handling? Perhaps another library is catching `SIGABRT`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/764#note_168558955 You're receiving 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 May 10 06:36:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 04:36:29 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) References: Message-ID: New Merge Request !995 https://gitlab.com/gnutls/gnutls/merge_requests/995 Branches: tmp-fix-srp to master Author: Nikos Mavrogiannopoulos Assignees: _gnutls_srp_entry_free would previously not free any parameters that were known to gnutls to account for documented behavior of gnutls_srp_set_server_credentials_function(). This was not updated when the newly added 8192 parameter was added to the library. This introduces a safety check for generator parameters, even though in practice they are the same pointer. ## 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/995 You're receiving 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 May 10 09:40:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 07:40:03 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/auth/srp_passwd.c: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168596894 > _gnutls_free_datum(&entry->salt); > > if ((entry->g.data != gnutls_srp_1024_group_generator.data) > - && (entry->g.data != gnutls_srp_3072_group_generator.data)) LGTM. There is just this inconsistency in breaking lines. Here you use `&& (expr)` and below `expr &&`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168596894 You're receiving 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 May 10 09:40:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 07:40:31 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Merge Request !995 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/995 Branches: tmp-fix-srp to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995 You're receiving 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 May 10 09:41:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 07:41:56 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Doesn't his close #761 ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168597469 You're receiving 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 May 10 11:24:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 09:24:15 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) In-Reply-To: References: Message-ID: Reassigned Issue 761 https://gitlab.com/gnutls/gnutls/issues/761 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761 You're receiving 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 May 10 11:25:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 09:25:21 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Ouch, correct. Updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168644547 You're receiving 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 May 10 11:25:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 09:25:55 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/srp_passwd.c: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168644761 > _gnutls_free_datum(&entry->salt); > > if ((entry->g.data != gnutls_srp_1024_group_generator.data) > - && (entry->g.data != gnutls_srp_3072_group_generator.data)) Right, fixed in the update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995#note_168644761 You're receiving 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 May 10 11:25:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 09:25:55 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: All discussions on Merge Request !995 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/995 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995 You're receiving 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 May 10 12:55:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 10:55:42 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) References: Message-ID: New Merge Request !996 https://gitlab.com/gnutls/gnutls/merge_requests/996 Branches: tmp-fix-gcc4.4 to master Author: Tim R?hsen Assignees: Fixes two small issues when building with gcc-4.4. ## 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/996 You're receiving 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 May 10 13:00:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 11:00:10 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: All discussions on Merge Request !994 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/994 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994 You're receiving 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 May 10 13:00:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 11:00:14 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Merge Request !994 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/994 Branches: tmp-lgtm-suppress-ctime to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994 You're receiving 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 May 10 13:00:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 11:00:09 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on src/certtool.c: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168677561 > > if (ca_crt && (secs > gnutls_x509_crt_get_expiration_time(ca_crt))) { > time_t exp = gnutls_x509_crt_get_expiration_time(ca_crt); > - fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); > - fprintf(stderr, "CA expiration time: %s", ctime(&exp)); > + fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); //lgtm [cpp/potentially-dangerous-function] LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168677561 You're receiving 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 May 10 13:00:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 11:00:39 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Reassigned Merge Request 994 https://gitlab.com/gnutls/gnutls/merge_requests/994 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994 You're receiving 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 May 10 13:35:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 11:35:53 +0000 Subject: [gnutls-devel] GnuTLS | Fix endless looping GETPORT in tests/scripts/common.sh (!997) References: Message-ID: New Merge Request !997 https://gitlab.com/gnutls/gnutls/merge_requests/997 Branches: tmp-fix-GETPORT to master Author: Tim R?hsen Assignees: I experienced endless running tests/suite/testcompat-tls13-openssl.sh which was due to GETPORT endlessly looping and waiting for a chosen port to become unused. The fix was to re-calculate the port number if it is busy. I'm sure this was the original intention, but somehow the random number was only calculated once. ## 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/997 You're receiving 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 May 10 14:51:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 12:51:50 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free safety feature bug (#761) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #761: https://gitlab.com/gnutls/gnutls/issues/761 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/761 You're receiving 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 May 10 14:51:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 12:51:50 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls_srp_entry_free: follow consistent behavior in freeing data (!995) In-Reply-To: References: Message-ID: Merge Request !995 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/995 Branches: tmp-fix-srp to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/995 You're receiving 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 May 10 15:52:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 13:52:52 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/tls-record-size-limit-asym.c: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168746474 > + /* General init. */ > + gnutls_global_set_log_function(tls_log_func); > + if (debug) > + gnutls_global_set_log_level(6); > + > + /* Init server */ > + gnutls_certificate_allocate_credentials(&serverx509cred); > + gnutls_certificate_set_x509_key_mem(serverx509cred, > + &server2_cert, &server2_key, > + GNUTLS_X509_FMT_PEM); > + > + gnutls_init(&server, GNUTLS_SERVER); > + gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, > + serverx509cred); > + > + gnutls_priority_set_direct(server, test->prio, NULL); Added `assert` here around the call. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_168746474 You're receiving 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 May 10 15:53:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 13:53:15 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: All discussions on Merge Request !985 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/985 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985 You're receiving 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 May 10 19:22:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 17:22:53 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Merge Request !994 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/994 Branches: tmp-lgtm-suppress-ctime to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994 You're receiving 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 May 10 22:19:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 20:19:59 +0000 Subject: [gnutls-devel] GnuTLS | tools: suppress ctime() error from lgtm warnings (!994) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on src/certtool.c: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168872621 > > if (ca_crt && (secs > gnutls_x509_crt_get_expiration_time(ca_crt))) { > time_t exp = gnutls_x509_crt_get_expiration_time(ca_crt); > - fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); > - fprintf(stderr, "CA expiration time: %s", ctime(&exp)); > + fprintf(stderr, "\nExpiration time: %s", ctime(&secs)); //lgtm [cpp/potentially-dangerous-function] @nmav Fun fact: Just randomly detected ctime() in multi-threaded code in Wget2, copied long time ago from gnutls-cli. So much to copy&paste stuff ;-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/994#note_168872621 You're receiving 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 May 10 23:19:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 10 May 2019 21:19:22 +0000 Subject: [gnutls-devel] GnuTLS | Should we check each argument of public gnutls functions to prevent crashes ? (#763) In-Reply-To: References: Message-ID: We should combine this with `_Nonnull` resp. `__attribute__ ((nonnull))`. Any pointer argument that isn't checked against NULL should have this attribute. That definitely helps static analyzers to find possible crashes, but it doesn't help applications if their devs don't use them. Also, gcc tends to optimize away param checks against NULL if the param is tagged nonnull. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/763#note_168882890 You're receiving 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 May 13 17:53:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 13 May 2019 15:53:27 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: All discussions on Merge Request !987 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/987 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 13 17:58:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 13 May 2019 15:58:04 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: I updated the patch along those lines, but after adding the `tls13_ok` field in `gnutls_certificate_credentials_st`, the ABI check started to complain. Do you have any idea to suppress it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_169594655 You're receiving 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 May 13 18:01:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 13 May 2019 16:01:49 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: rebased and added NEWS entry -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992#note_169596016 You're receiving 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 May 13 20:44:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 13 May 2019 18:44:37 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: fix carry flag in Streebog code (!992) In-Reply-To: References: Message-ID: Merge Request !992 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/992 Project:Branches: GostCrypt/gnutls:fix-streebog to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/992 You're receiving 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 May 14 02:09:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 00:09:02 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: This pull request **introduces 3 alerts** when merging 7a80b526cb290763adfb633df20fb7dce0a7192d into 6095a50c62535164bf8347c7ff922863a1b372ff - [view on LGTM.com](https://lgtm.com/projects/gl/gnutls/gnutls/rev/pr-3edc37db716a1c6284247975109b0df0e012aab2) **new alerts:** * 2 for FIXME comment * 1 for Missing header guard --- *Comment posted by [LGTM.com](https://lgtm.com)* -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_169714805 You're receiving 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 May 14 07:54:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 05:54:35 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Thank you for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985#note_169765545 You're receiving 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 May 14 08:05:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 06:05:17 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: distinguish sending and receiving limits (!985) In-Reply-To: References: Message-ID: Merge Request !985 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/985 Branches: tmp-record-sizes to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/985 You're receiving 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 May 14 11:33:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 09:33:07 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/tls-sig.c: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_169880482 > return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > > gnutls_sign_algorithm_set_client(session, sign_algo); > + pk_algo = gnutls_pubkey_get_pk_algorithm(cert->pubkey, NULL); @nmav No, we can not change this part of the spec, as it will break backwards compatibility with existing implementations. My initial implementation did the byteswap directly at `lib/tls-sig.c`. That way I did not have to change `gnutls_x509_spki_st`, did not add another flag, etc. But the code was local to `tls-sig.c`. Maybe that sounds better. Note, this byteswap has to be done only for TLS VerifyCert signature. I do not know who and why have made this crazy decision. Regarding making LE change part of signature algorithm. I think this will require me to duplicate sig_alg entries, won't it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_169880482 You're receiving 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 May 14 13:54:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 11:54:27 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: @nmav I'm getting a little bit stuck here because of 256-bit GOST groups. There are 4 groups defined (both by draft and by IANA), which correspond to 9 ECC Curves. Curves use same parameter values, same generators but have different OIDs. I have tried inverting group->curve relationship in GnuTLS code, but this resulted in quite ugly code for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_169979046 You're receiving 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 May 14 20:30:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 18:30:30 +0000 Subject: [gnutls-devel] GnuTLS | Deadlock in _gnutls_epoch_get on mutex epoch_lock with msmtp and gnutls 3.6.7 (#758) In-Reply-To: References: Message-ID: Is there any indication that the problem is in gnutls? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/758#note_170180770 You're receiving 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 May 14 21:03:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:03:57 +0000 Subject: [gnutls-devel] GnuTLS | Fix endless looping GETPORT in tests/scripts/common.sh (!997) In-Reply-To: References: Message-ID: Merge Request !997 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/997 Branches: tmp-fix-GETPORT to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/997 You're receiving 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 May 14 21:06:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:06:19 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/gthreads.h: https://gitlab.com/gnutls/gnutls/merge_requests/996#note_170189097 > > #include > > -#ifdef HAVE_THREADS_H > +/* Using a C99-only compiler installed in parallel with modern C11 environment > + * will see HAVE_THREADS_H, but won't be able to use _Thread_local. */ > +#if __STDC_VERSION__ >= 201112 && !defined __STDC_NO_THREADS__ && defined HAVE_THREADS_H I'd use parenthesis in the defined macros for consistency with the rest of the clauses -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996#note_170189097 You're receiving 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 May 14 21:08:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:08:31 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: Other than the comment it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996#note_170189600 You're receiving 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 May 14 21:17:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:17:56 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: You may need to rebase to master. Checking this branch it seems that it does not have the updated Makefile.am. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170191890 You're receiving 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 May 14 21:19:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:19:25 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.h: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170192184 > /* OCSP */ > gnutls_status_request_ocsp_func glob_ocsp_func; > void *glob_ocsp_func_ptr; /* corresponding OCSP response function */ > + > + bool tls13_ok; should we add a comment to clarify that this is only checked in server side? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170192184 You're receiving 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 May 14 21:21:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:21:33 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170192674 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY isn't this error we return misleading? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170192674 You're receiving 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 May 14 21:26:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:26:18 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't add CDP from the template (#765) References: Message-ID: New Issue was created. Issue 765: https://gitlab.com/gnutls/gnutls/issues/765 Author: Thomas Karlsson Assignees: ## Description of problem: CRL Distribution Point is not written to signed certificate, when specified in template. ## Version of gnutls used: 3.6.5 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu (3.6.5-2ubuntu1) ## How reproducible: root-ca.cfg `organization = "Initech" cn = "Initech Root CA" expiration_days = 700 ca cert_signing_key crl_signing_key ` ca.cfg `organization = "Initech" cn = "Initech CA" expiration_days = 350 crl_dist_points = "http://crl.initech.lan/Initech_Root_CA.crl" ca signing_key cert_signing_key crl_signing_key path_len = 0 ` `certtool --generate-privkey --sec-param high --outfile Initech_Root_CA-key.pem certtool --generate-self-signed --load-privkey Initech_Root_CA-key.pem --template root-ca.cfg --outfile Initech_Root_CA-cert.pem certtool --generate-privkey --sec-param medium --outfile Initech_CA-key.pem certtool --generate-request --load-privkey Initech_CA-key.pem --template ca.cfg --outfile Initech_CA-csr.pem certtool --generate-certificate --load-ca-privkey Initech_Root_CA-key.pem --load-ca-certificate Initech_Root_CA-cert.pem --load-request Initech_CA-csr.pem --template ca.cfg --outfile Initech_CA-cert.pem ` ## Actual results: No CDP in subsidiary CA. The code doesn't honor the CDP in template. It only tries to copy CDP from the signing CA. It doesn't make sense to copy CDP from signing CA. The CDP is different for the CA and a signed certificate. ## Expected results: At least a CDP in certificate and preferrably only the ones in the template. ## Proposed fix: In certtool.c Remove gnutls_x509_crt_cpy_crl_dist_points(crt, ca_crt); Add get_crl_dist_point_set(crt) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/765 You're receiving 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 May 14 21:32:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:32:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: What's the relationship between curves and groups? If a group is selected how would the curve be selected if there are multiple? If some curves have the same parameters can we treat them as a single curve? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170195355 You're receiving 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 May 14 21:34:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:34:03 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!981) In-Reply-To: References: Message-ID: Thanks. Let me know if you cannot handle this. I think this should be included in our next release. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/981#note_170195628 You're receiving 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 May 14 21:39:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:39:30 +0000 Subject: [gnutls-devel] GnuTLS | XMPP connection fails: it's stuck waiting for and doesn't skip the line (#766) References: Message-ID: New Issue was created. Issue 766: https://gitlab.com/gnutls/gnutls/issues/766 Author: Daniel Clemente Laboreo Assignees: ## Description of problem: When speaking XMPP, it doesn't connect to a server and timeouts while waiting for the text ``) and then the ` starttls: waiting for: " starttls: sending: starttls: waiting for: "PLAINDIGEST-MD5SCRAM-SHA-1 starttls: received: error receiving starttls: waiting for: " starttls: sending: starttls: waiting for: "PLAINDIGEST-MD5SCRAM-SHA-1 starttls: waiting for: " - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - X.509 Certificate Information: Version: 3 Serial Number (hex): 03e952752ec04bfcc10054d9701f6b98b2db Issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US Validity: Not Before: Thu Apr 11 09:56:22 UTC 2019 Not After: Wed Jul 10 09:56:22 UTC 2019 Subject: CN=jabberes.org [?] ``` ## Patch Attention, this isn't a full patch, it's a workaround. I don't speak the XMPP protocol yet so I don't know when do we expect to see a `` and when not, or what does it mean. A better option would be to ignore `` if it's there, but not to fail if it isn't. The patch just expects to see both lines one after the other, which works for jabberes.org ``` diff --git a/src/socket.c b/src/socket.c index be60f94..498d93f 100644 --- a/src/socket.c +++ b/src/socket.c @@ -250,6 +250,7 @@ socket_starttls(socket_st * socket) send_line(socket, buf); wait_for_text(socket, ""); + wait_for_text(socket, "app_proto, "ldap") == 0) { if (socket->verbose) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/766 You're receiving 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 May 14 21:43:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:43:26 +0000 Subject: [gnutls-devel] GnuTLS | Check all memory allocation in examples and certtool (!998) References: Message-ID: New Merge Request !998 https://gitlab.com/gnutls/gnutls/merge_requests/998 Branches: tmp-check-allocations to master Author: Nikos Mavrogiannopoulos Assignees: This adds missing memory allocation checks in examples and certtool. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature ## 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/998 You're receiving 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 May 14 21:53:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:53:55 +0000 Subject: [gnutls-devel] GnuTLS | Eliminate alloca() use in the guile bindings (#684) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684 You're receiving 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 May 14 21:57:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:57:08 +0000 Subject: [gnutls-devel] GnuTLS | Eliminate alloca() use in the guile bindings (#684) In-Reply-To: References: Message-ID: I'm removing any milestone from this issue and I'm assigning a special tag for guile bindings issues. We may consider in the future separating the guile bindings from the main gnutls library for easier handling of issues and releases. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684#note_170200786 You're receiving 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 May 14 21:59:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 19:59:31 +0000 Subject: [gnutls-devel] GnuTLS | Provide a configuration file (#587) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/587 You're receiving 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 May 14 22:23:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 20:23:07 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) References: Message-ID: New Issue was created. Issue 767: https://gitlab.com/gnutls/gnutls/issues/767 Author: Thomas Karlsson Assignees: ## Description of problem: Certtool does not put keyusage Signing when specified in template, when specifying "ca" in temp late. ## Version of gnutls used: 3.6.5 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu (3.6.5-2ubuntu1) ## How reproducible: root-ca.cfg organization = "Initech"\ cn = "Initech Root CA"\ expiration_days = 700\ ca\ cert_signing_key\ crl_signing_key ca.cfg organization = "Initech"\ cn = "Initech CA"\ expiration_days = 350\ crl_dist_points = "http://crl.initech.lan/Initech_Root_CA.crl"\ ca\ signing_key\ cert_signing_key\ crl_signing_key\ path_len = 0 certtool --generate-privkey --sec-param high --outfile Initech_Root_CA-key.pem\ certtool --generate-self-signed --load-privkey Initech_Root_CA-key.pem --template root-ca.cfg --outfile Initech_Root_CA-cert.pem\ certtool --generate-privkey --sec-param medium --outfile Initech_CA-key.pem\ certtool --generate-request --load-privkey Initech_CA-key.pem --template ca.cfg --outfile Initech_CA-csr.pem\ certtool --generate-certificate --load-ca-privkey Initech_Root_CA-key.pem --load-ca-certificate Initech_Root_CA-cert.pem --load-request Initech_CA-csr.pem --template ca.cfg --outfile Initech_CA-cert.pem ## Actual results: Keyusage "Signing" is not in subsidiary CA, even when specified in template. The code only allows this when the certificate is NOT a CA or it is a server certificate.\ Subsidiary CA's should have the keyusage "Signing". ## Expected results: Keyusage "Signing" should be in certificate of the subsidiary CA. ## Proposed fix: Add a new option called "subca". Allow option subca to add GNUTLS_KEY_DIGITAL_SIGNATURE. (Line 554) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767 You're receiving 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 May 14 22:37:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 20:37:35 +0000 Subject: [gnutls-devel] GnuTLS | Check all memory allocation in examples and certtool (!998) In-Reply-To: References: Message-ID: Merge Request !998 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/998 Branches: tmp-check-allocations to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/998 You're receiving 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 May 14 22:40:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 20:40:49 +0000 Subject: [gnutls-devel] GnuTLS | Fix endless looping GETPORT in tests/scripts/common.sh (!997) In-Reply-To: References: Message-ID: Merge Request !997 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/997 Branches: tmp-fix-GETPORT to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/997 You're receiving 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 May 15 00:46:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 14 May 2019 22:46:42 +0000 Subject: [gnutls-devel] GnuTLS | Lot's of warnings compiling with newer gcc (#768) References: Message-ID: New Issue was created. Issue 768: https://gitlab.com/gnutls/gnutls/issues/768 Author: Simo Sorce Assignees: When compiling with the latest gcc on Fedora I get the following warning everywhere: gcc: warning: switch '-Wchkp' is no longer supported GCC used: $ gcc --version gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1) I see there is a test in configure to see if gcc supports -Wchkp, perhaps it should be enhanced to figure out gcc doesn't like that flag anymore and suppress it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/768 You're receiving 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 May 15 06:52:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 04:52:16 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from jianqiang.wang@securitygossip.com): potential null pointer de-reference bugs. (#739) In-Reply-To: References: Message-ID: Reassigned Issue 739 https://gitlab.com/gnutls/gnutls/issues/739 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/739 You're receiving 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 May 15 06:52:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 04:52:37 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from jianqiang.wang@securitygossip.com): potential null pointer de-reference bugs. (#739) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #739: https://gitlab.com/gnutls/gnutls/issues/739 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/739 You're receiving 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 May 15 06:52:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 04:52:37 +0000 Subject: [gnutls-devel] GnuTLS | Check all memory allocation in examples and certtool (!998) In-Reply-To: References: Message-ID: Merge Request !998 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/998 Branches: tmp-check-allocations to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/998 You're receiving 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 May 15 06:57:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 04:57:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tls-sig.c: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170418975 > return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > > gnutls_sign_algorithm_set_client(session, sign_algo); > + pk_algo = gnutls_pubkey_get_pk_algorithm(cert->pubkey, NULL); I was thinking of a property of signature algorithms, that says "byteswap when doing tls sig", and add this property only to these algorithms. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170418975 You're receiving 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 May 15 07:01:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 05:01:28 +0000 Subject: [gnutls-devel] GnuTLS | Test failure in test-ciphers-api.sh (#764) In-Reply-To: References: Message-ID: No idea. If you create a small application that calls `assert()` -that's what the tests check for- does that raise sigill? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/764#note_170419572 You're receiving 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 May 15 10:28:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 08:28:35 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib for gcc-9 manywarnings (!999) References: Message-ID: New Merge Request !999 https://gitlab.com/gnutls/gnutls/merge_requests/999 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignees: Updating gnulib manywarnings module. Closes #768 ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [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/999 You're receiving 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 May 15 10:29:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 08:29:15 +0000 Subject: [gnutls-devel] GnuTLS | Lot's of warnings compiling with newer gcc (#768) In-Reply-To: References: Message-ID: See MR !999 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/768#note_170482643 You're receiving 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 May 15 12:00:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 10:00:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170523000 There are several "families" of curves: 1. GC256A group - id-tc26-gost-3410-12-256-paramSetA 2. GC256B group - id-tc26-gost-3410-12-256-paramSetB - id-GostR3410-2001-CryptoPro-A-ParamSet - id-GostR3410-2001-CryptoPro-XchA-ParamSet 3. GC256C group - id-tc26-gost-3410-12-256-paramSetC - id-GostR3410-2001-CryptoPro-B-ParamSet 4. GC256D group - id-tc26-gost-3410-12-256-paramSetD - id-GostR3410-2001-CryptoPro-C-ParamSet - id-GostR3410-2001-CryptoPro-XchB-ParamSet All curves from the "family"/group share all parameters except OID. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170523000 You're receiving 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 May 15 12:58:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 10:58:33 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170545951 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY It seems this is the requirement of RFC7919: https://gitlab.com/gnutls/gnutls/blob/master/lib/algorithms/ciphersuites.c#L1590 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170545951 You're receiving 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 May 15 12:59:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 10:59:18 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170546234 Ah, I didn't realize that; rebased. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_170546234 You're receiving 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 May 15 13:29:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 11:29:48 +0000 Subject: [gnutls-devel] GnuTLS | XMPP connection fails: it's stuck waiting for and doesn't skip the line (#766) In-Reply-To: References: Message-ID: We already fixed a related issue for 3.6.7 in commit 34988aa20369cb71e59b94772132b5efab6bc076. Could you test with at least that commit to see if your issue is gone (or not) ? If not, I'll investigate deeper (and come back to your patch). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/766#note_170556604 You're receiving 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 May 15 19:38:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 15 May 2019 17:38:11 +0000 Subject: [gnutls-devel] GnuTLS | Lot's of warnings compiling with newer gcc (#768) In-Reply-To: References: Message-ID: Ah interesting, didn't realize it was in gnulib, unfortunately I have no expertise in that area, so I'll wait for someone with more clues to review !999 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/768#note_170704782 You're receiving 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 May 16 06:15:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 04:15:01 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib for gcc-9 manywarnings (!999) In-Reply-To: References: Message-ID: Merge Request !999 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/999 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/999 You're receiving 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 May 16 09:32:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 07:32:10 +0000 Subject: [gnutls-devel] GnuTLS | Lot's of warnings compiling with newer gcc (#768) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #768: https://gitlab.com/gnutls/gnutls/issues/768 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/768 You're receiving 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 May 16 09:32:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 07:32:12 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib for gcc-9 manywarnings (!999) In-Reply-To: References: Message-ID: Merge Request !999 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/999 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/999 You're receiving 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 May 16 09:32:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 07:32:42 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib for gcc-9 manywarnings (!999) In-Reply-To: References: Message-ID: Thanks @dueno :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/999#note_170853169 You're receiving 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 May 16 11:34:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 09:34:55 +0000 Subject: [gnutls-devel] GnuTLS | XMPP connection fails: it's stuck waiting for and doesn't skip the line (#766) In-Reply-To: References: Message-ID: Issue was closed by Daniel Clemente Laboreo Issue #766: https://gitlab.com/gnutls/gnutls/issues/766 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/766 You're receiving 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 May 16 11:34:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 09:34:54 +0000 Subject: [gnutls-devel] GnuTLS | XMPP connection fails: it's stuck waiting for and doesn't skip the line (#766) In-Reply-To: References: Message-ID: It works! 3.6.7 fixes the issue, and the command always connects. emacs-jabber also works normally. Thanks. The relevant part of the connection with 3.6.7: ``` starttls: sending: starttls: waiting for: "PLAINDIGEST-MD5SCRAM-SHA-1 starttls: received: - Certificate type: X.509 - Got a certificate list of 2 certificates. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/766#note_170926292 You're receiving 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 May 16 11:42:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 09:42:20 +0000 Subject: [gnutls-devel] GnuTLS | XMPP connection fails: it's stuck waiting for and doesn't skip the line (#766) In-Reply-To: References: Message-ID: Thanks for testing ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/766#note_170929591 You're receiving 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 May 16 14:19:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 12:19:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170989637 Does this mean that "id-tc26-gost-3410-12-256-paramSetB", "id-GostR3410-2001-CryptoPro-A-ParamSet" and "id-GostR3410-2001-CryptoPro-XchA-ParamSet" are aliases to the same curve? If yes, does it matter to distinguish them? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_170989637 You're receiving 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 May 16 14:49:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 12:49:05 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: @nmav I think this is ready for review now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171002335 You're receiving 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 May 16 19:03:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 17:03:34 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_171114657 Yes, they are aliases to the same curve. Technically. However e.g. you should not be able to use two different curves in VKO key exchange. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_171114657 You're receiving 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 May 16 21:37:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 19:37:33 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) References: Message-ID: New Issue was created. Issue 769: https://gitlab.com/gnutls/gnutls/issues/769 Author: BigGosh Assignees: ## Description of problem: I run the command `git clone https://github.com/creationix/nvm.git -b v0.34.0 --depth=1` and the following error is displayed: > fatal: unable to access 'https://github.com/creationix/nvm.git/': GnuTLS recv error (-54): Error in the pull function. I've tried with many different github reposiroties Obviously the link is correctly accessible from my network. If I recompile git without GnuTLS but with OpenSSL git works fine. I've opened a bug on ubuntu but they said me it's not a their problem (Bug 1826598 - > https://bugs.launchpad.net/ubuntu/+source/git/+bug/1826598 ). ## Version of gnutls used: 3.6.5-2ubuntu1 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) ubuntu 19.04 ## How reproducible: Steps to Reproduce: * run the command `git clone https://github.com/creationix/nvm.git -b v0.34.0 --depth=1` * wait some timeout * see the error ## Actual results: An error ## Expected results: The clone of the repository -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769 You're receiving 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 May 16 22:54:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 16 May 2019 20:54:39 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: What does `GNUTLS_DEBUG_LEVEL=9 git clone ...` print ? And what does `gnutls-cli -d 999 github.com 443` say ? There must be a READ that fails... (that is the only place where you can get a -54 error). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171200365 You're receiving 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 May 17 09:30:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:30:53 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171302772 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Checking a little the code, it seems that this will never be executed (Q is never set in TLS even for known-rfc7919- parameters). Is that ok? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171302772 You're receiving 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 May 17 09:33:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:33:17 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Merge Request !990 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/990 Project:Branches: simo5/gnutls:ec-dh-keys-tests to gnutls/gnutls:master Author: Simo Sorce Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990 You're receiving 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 May 17 09:33:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:33:22 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Merge Request !990 was unapproved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/990 Project:Branches: simo5/gnutls:ec-dh-keys-tests to gnutls/gnutls:master Author: Simo Sorce Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990 You're receiving 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 May 17 09:33:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:33:36 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: LGTM modulo the comment. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171305145 You're receiving 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 May 17 09:41:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:41:48 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171314420 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY Hmm, but is that what is happening here? I am not sure what exactly this test entails but it should be failing due to no corresponding certificate found (which maps to `GNUTLS_E_NO_CIPHER_SUITES`) right? I do not see why it should reach the mismatch in FFDHE. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171314420 You're receiving 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 May 17 09:45:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:45:00 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/gthreads.h: https://gitlab.com/gnutls/gnutls/merge_requests/996#note_171317387 > > #include > > -#ifdef HAVE_THREADS_H > +/* Using a C99-only compiler installed in parallel with modern C11 environment > + * will see HAVE_THREADS_H, but won't be able to use _Thread_local. */ > +#if __STDC_VERSION__ >= 201112 && !defined __STDC_NO_THREADS__ && defined HAVE_THREADS_H Done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996#note_171317387 You're receiving 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 May 17 09:45:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:45:06 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: All discussions on Merge Request !996 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/996 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996 You're receiving 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 May 17 09:54:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 07:54:00 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: Merge Request !996 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/996 Branches: tmp-fix-gcc4.4 to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996 You're receiving 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 May 17 11:07:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 09:07:10 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_171407239 What if we assign these a single curve ID and we add multiple entries with the different OIDs? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_171407239 You're receiving 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 May 17 11:15:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 09:15:30 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171411833 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY This comes from: https://gitlab.com/gnutls/gnutls/blob/master/lib/algorithms/ciphersuites.c#L1583 If I disable FFDHE, by adding ":-GROUP-ALL:+GROUP-X25519", it gets `GNUTLS_E_NO_CIPHER_SUITES`. Do you want to do that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171411833 You're receiving 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 May 17 11:24:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 09:24:23 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: [git_clone_debug.txt](/uploads/b14e848637d1fe021c547506095e10c3/git_clone_debug.txt) [gnutls-cli.txt](/uploads/3806ccfcb26598b24d5643c8c39c4120/gnutls-cli.txt) Attached you can find output of the two commands you suggested. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171415813 You're receiving 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 May 17 11:39:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 09:39:54 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171424205 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY This would fix this test, but not the underlying issue. What is my concern is that when this downgrade to tls1.2 happens the server thinks that there is a mismatch in the FFDHE negotiation and returns this error, which is not the case here if I understand well. The reason of failure is because the key wasn't of the right type (RSA_PSS), is that right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171424205 You're receiving 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 May 17 13:54:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 11:54:51 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of functions gnutls_x509_crt_equals2 as const (!1000) References: Message-ID: New Merge Request !1000 https://gitlab.com/gnutls/gnutls/merge_requests/1000 Project:Branches: darktemplarbasealt/gnutls:mark_const to gnutls/gnutls:master Author: Aleksei Nikiforov Assignees: This will allow using this function with certificates returned by function gnutls_certificate_get_peers without casts dropping const qualifier or making temporary copies out of retrieved data. Make same changes for function gnutls_x509_crt_equals. ## 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/1000 You're receiving 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 May 17 14:22:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:22:19 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171500214 > .sig = GNUTLS_SIGN_RSA_PSS_SHA256, > .exp_kx = GNUTLS_KX_ECDHE_RSA, > }, > - {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */ > + {.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */ > .pk = GNUTLS_PK_RSA, > .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3", > .cert = &server_ca3_rsa_pss_cert, > .key = &server_ca3_rsa_pss_key, > + .sig = GNUTLS_SIGN_RSA_SHA256, > + .exp_kx = GNUTLS_KX_ECDHE_RSA, > + .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY OK, after discussing off-line, removed the special case for FFDHE in `lib/algorithms/ciphersuites.c`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171500214 You're receiving 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 May 17 14:22:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:22:32 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: All discussions on Merge Request !987 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/987 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 17 14:31:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:31:19 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: The error you are seeing is in `gnutls_bye()` call which is the call to close a connection. Typically applications ignore any error code there, basically because several servers in the past did not close connections properly. The error which the application should have seen due to log is the error in the push function due to `EPIPE` seen while writing the bye message. However the message in the error log you attach is error in the pull function. Not sure what is going on there, you may need to debug the application. How is git using gnutls there? I cannot see to find a reference of gnutls in its code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171503216 You're receiving 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 May 17 14:36:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:36:25 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171505001 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Soooo, the problem in using Q is that callers like the DH compute, use a structure with space for just two params (P, G), to get through the data to the lower layers. Is it ok to change those structures to optionally host Q as well ? If that is fine (unsure if it breaks ABI) then I can easily pass in Q in tests (and CAVS tests will be able to do the same. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171505001 You're receiving 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 May 17 14:38:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:38:45 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171505903 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { If that is ok I can also change initializers to always pass in Q in FIPS mode, but I am unsure we really want to pay the test computation penality. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171505903 You're receiving 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 May 17 14:56:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 12:56:03 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I don't know the tech details about git. I'm using the Ubuntu 19.04 standard package. They compile git with gnutls support. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171514757 You're receiving 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 May 17 16:16:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 14:16:08 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: Your bug report at Ubuntu seems to say that everybody else has no problems. It's just you. The conclusion is that there is something special in your network environment. We have to find out what it is and if we can do anything about it at all. I guess what @nmav means with 'what do you see on your network ?' is a tcpdump pcap file for further analysis in wireshark. Here is how it goes: - execute as root `tcpdump host github.com -w out.pcap` and wait 1-2s until tcpdump tells you that it is listening on port ... - in a second console, execute `git clone https://github.com/creationix/nvm.git -b v0.34.0 --depth=1` - when the git command is done, stop tcpdump with ctrl-c and upload `out.pcap` here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171548960 You're receiving 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 May 17 16:35:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 14:35:34 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/699#note_171556478 Actually no - the only issue with the known cause is (3), which hits the rate limit. I'm looking at the others now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_171556478 You're receiving 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 May 17 16:48:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 14:48:22 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171561688 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { The functions with underscore (e.g., _gnutls_dh_compute) are not part of API, and are only exported for the cavs testing, so I guess we can freely update. The challenge would be including Q in the known group information (algorithms/groups), and passing it down to nettle. That could work well for TLS1.3. However, the question is if FIPS mandates this test, what do we do under TLS1.3 when a non-known group is negotiated. Any suggestions? Dropping the connection may be too drastic, so it may even make sense to disable DHE under TLS1.2. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171561688 You're receiving 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 May 17 16:59:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 14:59:10 +0000 Subject: [gnutls-devel] GnuTLS | Tmp fix gcc4.4 (!996) In-Reply-To: References: Message-ID: Merge Request !996 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/996 Branches: tmp-fix-gcc4.4 to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/996 You're receiving 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 May 17 17:45:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 15:45:00 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171582411 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { The structure I was mentioning is struct gnutls_dh_params_int which is populated by gnutls_dh_params_init() It is marked as deprecated but still exported as opaque in gnutls/gnutls.h If it is ok to change it I can change it to hold 3 params and add Q during init. If Q testing will become mandatory then we can definitely return an error and disable DHE, otherwise it will just not be present when not available and the test will simply skip checking Q. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171582411 You're receiving 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 May 17 17:50:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 15:50:22 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Tom?? Mr?z commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171584176 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Actually I got already a word from Stephan that he talked with NIST to clarify and the Q testing (or in equivalent term comparison of the parameters to the known good safe primes) is mandatory even for TLS. So I'd say we are unfortunately forced to disable DHE in TLS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171584176 You're receiving 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 May 17 17:59:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 15:59:26 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171587252 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { We can always calculate Q in FIPS mode and just error if whatever was used is not a german prime, but probably disabling DHE will prove to be a better experience. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171587252 You're receiving 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 May 17 18:21:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 16:21:53 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: OK, I think I figured out the causes of 1 and 2: 1. we need to check `session->internals.handshake_header_recv_buffer.length` as well as `session->internals.handshake_recv_buffer_size` in `record_add_to_buffers`. should be a one-line fix. 2. The test expects that the reply comes before it sends the next ApplicationData, while GnuTLS defers the reply until it sends the next ApplicationData. As I mentioned in [another tlsfuzzer issue](https://github.com/tomato42/tlsfuzzer/issues/547#issuecomment-487591261), this is not technically wrong. @tomato42 what do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_171593568 You're receiving 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 May 17 21:28:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 19:28:38 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I attached the pcap file. My PC access Internet via a firewall which runs linux with iptables. For me, this problem started after the installation of new PC with Kubuntu 19.04. Thanks[out.pcap](/uploads/424c41c3d17e1dc04e4cd7cc00736b0e/out.pcap) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171674407 You're receiving 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 May 17 21:35:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 19:35:45 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171675775 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { > The structure I was mentioning is struct gnutls_dh_params_int which is populated by gnutls_dh_params_init() It is marked as deprecated but still exported as opaque in gnutls/gnutls.h If it is ok to change it I can change it to hold 3 params and add Q during init. This structure is only useful for tls1.2 or earlier, thus it may not make much sense to enhance it (see below). So, the options we have now are: 1. Implement tests with Q, and if not available bail out in FIPS mode; the tests will only be possible/efficient when the primes are known, i.e., TLS1.2 with RFC7919 or TLS1.3 (will most likely break some TLS1.2 connections) 2. Disable DHE completely and unconditionally when in FIPS mode (seems to be the easiest to implement, with probably minor incompatibility issues) 3. Disable DHE when used with TLS1.2 and FIPS mode, and implement tests with Q when used with TLS1.3 (where the Q is always known because only the known set of parameters is negotiated) However reading [SP800-56A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf), `5.6.2.3.2 FFC Partial Public-Key Validation Routine`, if we restrict to safe primes (i.e., the approved list in the appendix D) we don't need any additional check to what is already there. Given that the supported primes for TLS1.3 are the approved ones, we may simplify (3) as follows. 3. Disable DHE when used with TLS1.2 and FIPS mode. It seems a good compromise. What do you think? @smullerDD would that be acceptable in terms of FIPS? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171675775 You're receiving 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 May 17 21:36:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 19:36:46 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171675960 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { @smuellerDD ^^^ (I mistyped your username) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171675960 You're receiving 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 May 17 21:55:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 19:55:12 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171684942 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Uhmm I coded up the new patch I just pushed before you made the comment. So I just extended the dh_params structure and added tests to prove it works. Let me know if you still think I should change approach. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171684942 You're receiving 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 May 17 21:57:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 19:57:51 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171686272 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Note that my additions do not change anything in TLS yet, so we can have both my patches in so CAVS/ACVP tests can be performed and also just disable DHE in TLS1.2 so we do not have to fail badly when y^q mod p does not pass with arbitrary DH primes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171686272 You're receiving 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 May 17 22:11:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:11:06 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos, i am not sure we do not need the test, as y comes for the peer, so we should probably still check it in TLS1.3 ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171691415 You're receiving 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 May 17 22:22:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:22:45 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171694887 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { If we disable DHE in TLS1.2 there is no practical value from the new test using Q because this catches incorrect public keys, but only in the non-safe groups (SP800-56A acknowledges that). I'd expect the ACVP/CAVS tests to be different depending on whether `SP800-56A 5.6.2.2.2 case 1` or case (2) is claimed. Let's see what Stephan thinks on that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171694887 You're receiving 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 May 17 22:27:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:27:30 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: > @nmav i am not sure we do not need the test, as y comes for the peer, so we should probably still check it in TLS1.3 ? In TLS1.3 only safe groups are supported, and this check is about whether the public key is on the correct subgroup. That makes sense for general groups, but in safe groups there are only 3 subgroups, the one generated by `1`, by `-1` and by `q`. 1 generates itself only, and -1 generates itself and 1. Thus by the check that `1 < y < p-1` we already ensure that y is generated by none of these groups. The test on whether y is generated by `q` is now superfluous because there is no other subgroup but q. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171696297 You're receiving 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 May 17 22:38:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:38:29 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767 You're receiving 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 May 17 22:43:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:43:22 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't add CDP from the template (#765) In-Reply-To: References: Message-ID: It makes sense to me. Would you like to propose a patch, and add a test case for it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/765#note_171700581 You're receiving 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 May 17 22:43:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 20:43:28 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't add CDP from the template (#765) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/765 You're receiving 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 May 17 23:13:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 21:13:26 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: The above may not be accurate as I seem to have missed the order 2q. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171707104 You're receiving 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 May 17 23:22:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 17 May 2019 21:22:55 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Stephan Mueller commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171709007 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Hi Nikos, > Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: > https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171694887 > > goto dh_cleanup; > > > > } > > > > + /* if we have Q check that y ^ q mod p == 1 */ > > + if (q != NULL) { > > If we disable DHE in TLS1.2 there is no practical value from the new test > using Q because this catches incorrect public keys, but only in the > non-safe groups (SP800-56A acknowledges that). I'd expect the ACVP/CAVS > tests to be different depending on whether `SP800-56A 5.6.2.2.2 case 1` or > case (2) is claimed. Let's see what Stephan thinks on that. The following is NOT yet official, but should guide your considerations. We just had a discussion with the responsible persons within NIST defining the crypto requirements. The following conclusion came out of the discussion that yet needs to be poured into a FIPS IG. - If we have Sophie-Germain primes, we must have a check of the remote key. For TLS, you will always be able to get the Q from the communicated P ( Q = (P - 1) / 2) ) or via a lookup-table. - If you get a random prime via TLS, you can dispense with the remote key check. - We have to expect that the ACVP testing will be updated to allow testing of DH with Sophie-Germain primes. - For the existing ACVP testing providing a random prime, the key check must be performed. That said, the check above should be updated to check that P references a Sophie-Germain prime and obtain Q if this is the case. Only if the Q value is not found after that P lookup, the q != NULL is good. Though, this solution is yet to be turned into an official statement. I expect an official statement in the not too far future. Until that happens, please leave the check in the code above for now. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_171709007 You're receiving 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 May 19 06:25:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 19 May 2019 04:25:05 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/699#note_171885394 If (2) is acceptable, I guess we could fix (3) by simply removing the limit expecting that the reply will only be sent before the next ApplicationData (unless we consider updating keys many times as DoS). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_171885394 You're receiving 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 May 19 15:19:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 19 May 2019 13:19:23 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't add CDP from the template (#765) In-Reply-To: References: Message-ID: Thomas Karlsson commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/765#note_171937391 I can try. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/765#note_171937391 You're receiving 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 May 19 21:28:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 19 May 2019 19:28:15 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: Your firewall seems to be improperly configured (Try open the out.pcap with wireshark and examine the black lines). To make sure if it's your firewall or another network device, disable your firewall and try the git command again (maybe capture the traffic again for comparison). Anyways, the result of the broken TCP/IP traffic might be a dropped connection with an unusual error code from the kernel. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_171994415 You're receiving 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 May 19 23:27:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 19 May 2019 21:27:34 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I tried "jumping" firewall and git works. Now I'll investigate but I report to you following points: * git compiled with openssl instead of gnutls works fine * standard git (comiled with gnutls I think) of ubuntu 18.04 works The only rule not executed now to make everything working well is the iptables nat rule Thanks for support If I'll found a better solution I'll reply to this bug report. (if the system will allow me) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_172023536 You're receiving 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 May 19 23:27:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 19 May 2019 21:27:35 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: Issue was closed by BigGosh Issue #769: https://gitlab.com/gnutls/gnutls/issues/769 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769 You're receiving 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 May 20 03:21:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 01:21:15 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: I am not sure what breaks the pipeline still, help? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172038519 You're receiving 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 May 20 08:12:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:12:45 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on devel/symbols.last: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073203 > gnutls_ext_set_data at GNUTLS_3_4 > gnutls_ffdhe_2048_group_generator at GNUTLS_3_4 > gnutls_ffdhe_2048_group_prime at GNUTLS_3_4 > +gnutls_ffdhe_2048_group_q at GNUTLS_3_6_8 Should we export them generally or only as necessary to use in the test suite? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073203 You're receiving 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 May 20 08:15:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:15:18 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/dh.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073652 > + bigint_t tmp_p, tmp_g, tmp_q = NULL; > + > + if (_gnutls_mpi_init_scan_nz(&tmp_p, prime->data, prime->size)) { > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + > + if (_gnutls_mpi_init_scan_nz(&tmp_g, generator->data, > + generator->size)) { > + _gnutls_mpi_release(&tmp_p); > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + > + /* Mandatory in FIPS mode */ > +#ifdef ENABLE_FIPS140 I think it is better to use the run-time check here. Otherwise we can enforce the test even when not in fips mode. `if (_gnutls_fips_mode_enabled() == 0) {` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073652 You're receiving 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 May 20 08:16:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:16:46 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/dh.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073925 > +#ifdef ENABLE_FIPS140 > + if (!q) { > + gnutls_assert(); > + return GNUTLS_E_DH_PRIME_UNACCEPTABLE; > + } else { > +#else > + if (q) { > +#endif > + if (_gnutls_mpi_init_scan_nz(&tmp_q, q->data, q->size)) { > + _gnutls_mpi_release(&tmp_p); > + _gnutls_mpi_release(&tmp_g); > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + } > + Should we add a sanity check to ensure that `g^q=1` to avoid any mistakes by entering the parameters in a different order? (the other function accepts p,g and this one p,q,g, and it may be easy to do something like p,g,q when converting to the new). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172073925 You're receiving 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 May 20 08:21:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:21:15 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/pk.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172074460 > goto dh_cleanup; > } > > + /* if we have Q check that y ^ q mod p == 1 */ > + if (q != NULL) { Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172074460 You're receiving 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 May 20 08:26:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:26:01 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Thanks for the update. What I notice is that it does not ensure that the `q` is set during TLS DH exchange. For TLS1.3 the relevant file is `ext/key_share.c` (e.g., `client_gen_key_share`) and under TLS1.2 the `auth/dh_common.c`. These currently only set g, and p. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172075787 You're receiving 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 May 20 08:28:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:28:24 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: For the failures one seems to be related with output of gnutls-cli-debug changing under address sanitizer (could indicate something caught by address sanitizer), and other other may require you to run `make files-update` on a run which you didn't use `--disable-docs`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172076265 You're receiving 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 May 20 08:30:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:30:11 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172076709 > if (c != NULL && c->ncerts != 0) { > for (i = 0; i < c->ncerts; i++) { > key_usage = get_key_usage(session, c->certs[i].cert_list[0].pubkey); > - if (key_usage == 0 || (key_usage & GNUTLS_KEY_DIGITAL_SIGNATURE)) { > + if ((key_usage == 0 || (key_usage & GNUTLS_KEY_DIGITAL_SIGNATURE))) { There is a double parenthesis here added, which doesn't add to logic -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172076709 You're receiving 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 May 20 08:31:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:31:17 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172076936 You're receiving 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 May 20 08:33:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:33:59 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: It seems though tlsfuzzer catches this change `AssertionError: Expected alert description "insufficient_security" does not match received "handshake_failure"` and doesn't seem to provide an override method. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172077491 You're receiving 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 May 20 08:35:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:35:57 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I wonder whether a patch like that would address this issue. ``` diff --git a/lib/buffers.c b/lib/buffers.c index 076a39f06b..a7bee75b11 100644 --- a/lib/buffers.c +++ b/lib/buffers.c @@ -225,6 +225,7 @@ int errno_to_gerr(int err, unsigned dtls) else return GNUTLS_E_PUSH_ERROR; case ECONNRESET: + case EPIPE: return GNUTLS_E_PREMATURE_TERMINATION; default: gnutls_assert(); ``` @BigGosh would you like to try that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_172077886 You're receiving 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 May 20 08:40:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 06:40:48 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: What about increasing the key updates per sec to something larger like 8 or 16? The reason this exists is mainly because there was a similar situation under tls1.2 where alert messages could be sent by the client continuously and cause a DoS on the server. To counter that a rate limit was introduced (with `handshake_suspicious_loops`), thus I thought it would be a good idea to limit these too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_172078997 You're receiving 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 May 20 10:11:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 08:11:44 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172110712 Yes, it is requested at https://github.com/tomato42/tlsfuzzer/pull/549 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172110712 You're receiving 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 May 20 11:13:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 09:13:44 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) References: Message-ID: New Merge Request !1001 https://gitlab.com/gnutls/gnutls/merge_requests/1001 Branches: tmp-fix-evil-idna to master Author: Tim R?hsen Assignees: Apply STD3 ASCII rules in gnutls_idna_map() to prevent hostname/domain crafting via IDNA conversion Closes #720 ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] 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/1001 You're receiving 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 May 20 11:18:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 09:18:17 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) In-Reply-To: References: Message-ID: Merge Request !1001 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1001 Branches: tmp-fix-evil-idna to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1001 You're receiving 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 May 20 11:18:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 09:18:31 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) In-Reply-To: References: Message-ID: LGTM but shouldn't that be documented in NEWS? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1001#note_172142753 You're receiving 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 May 20 11:18:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 09:18:43 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1001 You're receiving 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 May 20 11:25:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 09:25:20 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) In-Reply-To: References: Message-ID: Normally I leave it to the maintainer to edit NEWS. But NP, I'll add an entry. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1001#note_172146750 You're receiving 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 May 20 12:57:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 10:57:10 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) References: Message-ID: New Merge Request !1002 https://gitlab.com/gnutls/gnutls/merge_requests/1002 Branches: tmp-datum-cleanup to master Author: Tim R?hsen Assignees: Cleans up the two functions in datum.c. Adds a return value check in session.c. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [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/1002 You're receiving 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 May 20 13:35:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 11:35:18 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PROFILE_FUTURE missing (#770) References: Message-ID: New Issue was created. Issue 770: https://gitlab.com/gnutls/gnutls/issues/770 Author: Nikos Mavrogiannopoulos Assignees: Currently in `x509.h` we provide up to `GNUTLS_PROFILE_ULTRA` which corresponds to `GNUTLS_SEC_PARAM_ULTRA`. There is no corresponding profile for `GNUTLS_SEC_PARAM_FUTURE` (256-bits). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/770 You're receiving 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 May 20 14:27:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:27:14 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Thanks, LGTM. Please set CI timeout to 2h or higher (see Settings/CICD/General pipelines/Timeout) and restart the two failed jobs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172232565 You're receiving 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 May 20 14:30:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:30:52 +0000 Subject: [gnutls-devel] GnuTLS | Apply STD3 ASCII rules in gnutls_idna_map() (!1001) In-Reply-To: References: Message-ID: Merge Request !1001 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1001 Branches: tmp-fix-evil-idna to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1001 You're receiving 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 May 20 14:54:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:54:26 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on devel/symbols.last: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172244697 > gnutls_ext_set_data at GNUTLS_3_4 > gnutls_ffdhe_2048_group_generator at GNUTLS_3_4 > gnutls_ffdhe_2048_group_prime at GNUTLS_3_4 > +gnutls_ffdhe_2048_group_q at GNUTLS_3_6_8 I do not see any harm in making them generally available, they are just well known constants that cannot change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172244697 You're receiving 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 May 20 14:54:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:54:48 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/dh.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172244857 > + bigint_t tmp_p, tmp_g, tmp_q = NULL; > + > + if (_gnutls_mpi_init_scan_nz(&tmp_p, prime->data, prime->size)) { > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + > + if (_gnutls_mpi_init_scan_nz(&tmp_g, generator->data, > + generator->size)) { > + _gnutls_mpi_release(&tmp_p); > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + > + /* Mandatory in FIPS mode */ > +#ifdef ENABLE_FIPS140 ack, will change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172244857 You're receiving 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 May 20 14:56:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:56:19 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/dh.c: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172245476 > +#ifdef ENABLE_FIPS140 > + if (!q) { > + gnutls_assert(); > + return GNUTLS_E_DH_PRIME_UNACCEPTABLE; > + } else { > +#else > + if (q) { > +#endif > + if (_gnutls_mpi_init_scan_nz(&tmp_q, q->data, q->size)) { > + _gnutls_mpi_release(&tmp_p); > + _gnutls_mpi_release(&tmp_g); > + gnutls_assert(); > + return GNUTLS_E_MPI_SCAN_FAILED; > + } > + } > + Which is what I did in previous rebase :-) Inserting them in the wrong order breaks the dh-params test already, so I think we do not need additional tests here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172245476 You're receiving 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 May 20 14:57:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:57:46 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: ah make files-update fails on my F30 machine saying libopts in the tree needs updating ... I fear if I update that I may break someone else? What is the procedure here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172246087 You're receiving 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 May 20 14:58:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:58:04 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: > mainly because there was a similar situation under tls1.2 where alert messages could be sent by the client continuously and cause a DoS on the server. how is that different from a client that sends AppData records that are all padding? with tls1.2 the problem was that the attack was asymmetric ? the alerts were not encrypted, and caused a lot of CPU use on server ? here, the attacker and server have to perform the exact same operations, otherwise server will reject the key update as malformed note that the server doesn't have to answer 1-to-1 to every KeyUpdate request, it's valid to answer with just one KeyUpdate to those 20 KeyUpdates from the client, and it is ok to send that KeyUpdate only when, and right before, the AppData from server is sent (the test case would need to be updated to detect that though, IIRC) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_172246195 You're receiving 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 May 20 14:59:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 12:59:29 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: As for TLS, indeed this is not wired up yet, which is why the commit is title around "plumbing". I wanted to make sure this approach is ok first, and then open a separate MR to wire in the plumbing. However I can also wire everything in this MR if you give me directions on how you want to see this wired in. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172246846 You're receiving 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 May 20 16:13:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 14:13:57 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Thanks. Now CI tests passed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172290087 You're receiving 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 May 20 16:27:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 14:27:34 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) References: Message-ID: New Merge Request !1003 https://gitlab.com/gnutls/gnutls/merge_requests/1003 Project:Branches: nmav/gnutls:tmp-minor-fixes to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: This contains a patch set with minor bug fixes to be included before the new release. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [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/1003 You're receiving 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 May 20 16:28:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 14:28:09 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: These two functions call other functions with the now const arguments. These should have const arguments as well, right ? Didn't you see warnings about it !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172303595 You're receiving 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 May 20 16:29:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 14:29:12 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PROFILE_FUTURE missing (#770) In-Reply-To: References: Message-ID: Reassigned Issue 770 https://gitlab.com/gnutls/gnutls/issues/770 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/770 You're receiving 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 May 20 16:29:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 14:29:12 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) In-Reply-To: References: Message-ID: Reassigned Issue 767 https://gitlab.com/gnutls/gnutls/issues/767 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767 You're receiving 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 May 20 17:06:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 15:06:19 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1003 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on lib/includes/gnutls/x509.h: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172322396 > + * @GNUTLS_PROFILE_FUTURE: A verification profile that > + * corresponds to @GNUTLS_SEC_PARAM_FUTURE (256 bits) > % * @GNUTLS_PROFILE_SUITEB128: A verification profile that not introduced by this commit, but there is a stray '%' -- Daiki Ueno started a new discussion on tests/time.c: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172322400 > + * You should have received a copy of the GNU General Public License > + * along with GnuTLS; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA maybe good to update to the header template with license URL, instead of the address -- Daiki Ueno started a new discussion on tests/time.c: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172322402 > +/* > + * Copyright (C) 2016 Red Hat, Inc. copyright year? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003 You're receiving 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 May 20 17:07:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 15:07:04 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Looks good to me except the minor issues in comments. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172322825 You're receiving 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 May 20 17:07:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 15:07:39 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Merge Request !1003 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1003 Project:Branches: nmav/gnutls:tmp-minor-fixes to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003 You're receiving 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 May 20 18:00:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:00:09 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: You're right. For some reason I didn't get any warnings while there are functions called which use non-const arguments. Unfortunately, there is a chain of calls gnutls_x509_crt_equals2 -> gnutls_x509_crt_export2 -> _gnutls_x509_export_int_named2 -> _gnutls_x509_der_encode -> asn1_der_coding (from libtasn1), and it looks like libtasn1 extensively uses non-const arguments. Until it is changed to use const arguments as well where it can be used, this change would require a workaround for that. I don't want to make such workaround for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172359975 You're receiving 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 May 20 18:00:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:00:09 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Merge Request !1000 was closed by Aleksei Nikiforov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1000 Project:Branches: darktemplarbasealt/gnutls:mark_const to gnutls/gnutls:master Author: Aleksei Nikiforov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000 You're receiving 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 May 20 18:08:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:08:49 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/auth.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172363337 > if (c != NULL && c->ncerts != 0) { > for (i = 0; i < c->ncerts; i++) { > key_usage = get_key_usage(session, c->certs[i].cert_list[0].pubkey); > - if (key_usage == 0 || (key_usage & GNUTLS_KEY_DIGITAL_SIGNATURE)) { > + if ((key_usage == 0 || (key_usage & GNUTLS_KEY_DIGITAL_SIGNATURE))) { Thanks, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_172363337 You're receiving 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 May 20 18:08:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:08:59 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: All discussions on Merge Request !987 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/987 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 20 18:15:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:15:13 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: All discussions on Merge Request !990 were resolved by Simo Sorce https://gitlab.com/gnutls/gnutls/merge_requests/990 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990 You're receiving 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 May 20 18:17:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 16:17:05 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Ok so I tried to update libopts and run make files-update but it caused a huge diss in the .abi xml files, most of the diff looked cosmetic, where some function changed place or an index got changed early on and the changed casecaded in every single following definition. I did see a change I missed wrt docs, so I added that as well as the runtime fips check, and resubmitted for pipeline testing. Will see if I have to revive my commit to update libopts, which I would prefer to avoid. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172371717 You're receiving 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 May 20 21:32:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:32:12 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) In-Reply-To: References: Message-ID: Strictly speaking this flag is not necessary in CA or intermediate CA certificates according to rfc5280, as it says: ```If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set. ``` However, that does not prohibit it either. Thus we should allow that flag if requested. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767#note_172430354 You're receiving 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 May 20 21:37:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:37:33 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/time.c: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431366 > +/* > + * Copyright (C) 2016 Red Hat, Inc. Thanks, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431366 You're receiving 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 May 20 21:37:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:37:44 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/time.c: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431406 > + * > + * This file is part of GnuTLS. > + * > + * GnuTLS is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 3 of the License, or > + * (at your option) any later version. > + * > + * GnuTLS is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with GnuTLS; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA Thanks, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431406 You're receiving 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 May 20 21:37:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:37:51 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: All discussions on Merge Request !1003 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/1003 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003 You're receiving 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 May 20 21:37:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:37:53 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/x509.h: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431428 > * @GNUTLS_PROFILE_HIGH: A verification profile that > * corresponds to @GNUTLS_SEC_PARAM_HIGH (128 bits) > * @GNUTLS_PROFILE_ULTRA: A verification profile that > - * corresponds to @GNUTLS_SEC_PARAM_ULTRA (256 bits) > + * corresponds to @GNUTLS_SEC_PARAM_ULTRA (192 bits) > + * @GNUTLS_PROFILE_FUTURE: A verification profile that > + * corresponds to @GNUTLS_SEC_PARAM_FUTURE (256 bits) > % * @GNUTLS_PROFILE_SUITEB128: A verification profile that Nice catch, removed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003#note_172431428 You're receiving 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 May 20 21:41:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:41:29 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172432188 > return 0; > } > > - dat->data = gnutls_malloc(data_size); The advantage of the old code was that it would set the output datum to NULL if failed. Why the update? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172432188 You're receiving 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 May 20 21:44:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:44:46 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: > As for TLS, indeed this is not wired up yet, which is why the commit is title around "plumbing". I wanted to make sure this approach is ok first, and then open a separate MR to wire in the plumbing. However I can also wire everything in this MR if you give me directions on how you want to see this wired in. It makes more sense to me to bring any solution in one go, as the partial update will add code used only during testing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172433374 You're receiving 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 May 20 21:48:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:48:34 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Reassigned Merge Request 987 https://gitlab.com/gnutls/gnutls/merge_requests/987 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 20 21:48:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:48:38 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Merge Request !987 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/987 Branches: tmp-privkey-tls13 to master Author: Daiki Ueno Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 20 21:48:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:48:43 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Reassigned Merge Request 987 https://gitlab.com/gnutls/gnutls/merge_requests/987 Assignee changed from Nikos Mavrogiannopoulos to Nikos Mavrogiannopoulos and Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 20 21:48:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:48:48 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Reassigned Merge Request 987 https://gitlab.com/gnutls/gnutls/merge_requests/987 Assignee changed from Nikos Mavrogiannopoulos and Daiki Ueno to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 20 21:55:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:55:09 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: Something being valid is most of the times not enough to allow it in an implementation. It was also valid to send an infinite number of alerts, but we stopped that to avoid the DoS. We can have no limits an be re-active on the next attack, or put limits to prevent situations which do not make much sense. I'm in favor of the latter approach. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699#note_172435604 You're receiving 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 May 20 21:56:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 19:56:46 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: @darktemplarbasealt Well, I didn't mean the MR shouldn't apply when that chain can't be resolved. The reason you gave in the description is IMO valid. @nmav WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172435876 You're receiving 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 May 20 22:04:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:04:48 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172444707 > return 0; > } > > - dat->data = gnutls_malloc(data_size); I just ran across it randomly. Functions that change their output params on error are IMO bad design. I wouldn't expect that as a regular user of all kinds of APIs. In my own projects I consider such behavior as bug. Other devs do so as well as bug reports from the past show that. NP if you disagree and want to keep it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172444707 You're receiving 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 May 20 22:14:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:14:11 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172463387 > return 0; > } > > - dat->data = gnutls_malloc(data_size); It may be in general but in this particular case it looks like a safety feature. Both of these functions are initialization functions, and for code like: ``` _gnutls_set_datum(x, "y", 1); printf("%s", x.data); ``` when allocation fails, they will prevent an uninitialized x.data to be passed to printf(). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172463387 You're receiving 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 May 20 22:18:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:18:52 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172473816 > return 0; > } > > - dat->data = gnutls_malloc(data_size); As these functions predate modern asan and gcc attributes their conservative-ness may not make much sense. If we are to remove that check, I think it makes sense to use gcc attributes or something similar to prevent misuse. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172473816 You're receiving 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 May 20 22:21:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:21:58 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172480541 > return 0; > } > > - dat->data = gnutls_malloc(data_size); You mean the malloc attribute or is there something else we can do !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172480541 You're receiving 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 May 20 22:22:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:22:23 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: We didn't use the const argument enough for the certificate types and the API evolved against that good practice. It may be hard to introduce it now though I would certainly be in favor for such enhancement. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172481303 You're receiving 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 May 20 22:23:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:23:57 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: I was thinking of the attribute about unchecked returned value (not sure of the accurate name) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172484642 You're receiving 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 May 20 22:26:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:26:49 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: `warn_unused_result` seems to be it -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172486841 You're receiving 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 May 20 22:27:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:27:32 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: I go for it tomorrow incl. gcc version checks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172486965 You're receiving 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 May 20 22:28:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:28:57 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: > though I would certainly be in favor for such enhancement. Yes, me too. Maybe start with the libtasn API !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172487251 You're receiving 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 May 20 22:57:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 20:57:03 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: I was able to avoid updating autogenerated files, the last failure is a missing free that I already figured out. I am adding code now to deal with using Q in tls1.3 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172496077 You're receiving 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 May 20 23:16:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 20 May 2019 21:16:54 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I was not able to test the patch yet, but I found the following strange behavior. 1. my firewall is based on a cubietruck with armbian installed. Details are: > root at cubie:~# cat /etc/debian_version > 8.11 > root at cubie:~# cat /etc/os-release > PRETTY_NAME="Debian GNU/Linux 8 (jessie)" > NAME="Debian GNU/Linux" > VERSION_ID="8" > VERSION="8 (jessie)" > ID=debian > HOME_URL="http://www.debian.org/" > SUPPORT_URL="http://www.debian.org/support" > BUG_REPORT_URL="https://bugs.debian.org/" 2. I installed an other board ARM based with ubuntu and configured the basic iptables rule to allow me to test the NAT and this time git works. 3. the two ARM chips on the two boards are the same So, on my opinion, is something in debian configuration/compilation options that breaks the NAT flow. For test on the patch, please wait till the next week end. This take more time, as I'm not so confident with ubntu package recompiling procedure. THANKS and I hope to be of any help with the above information -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_172500850 You're receiving 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 May 21 05:48:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:40 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PROFILE_FUTURE missing (#770) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #770: https://gitlab.com/gnutls/gnutls/issues/770 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/770 You're receiving 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 May 21 05:48:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:41 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PROFILE_FUTURE missing (#770) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #770: https://gitlab.com/gnutls/gnutls/issues/770 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/770 You're receiving 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 May 21 05:48:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:40 +0000 Subject: [gnutls-devel] GnuTLS | Few minor bug fixes for the next release (!1003) In-Reply-To: References: Message-ID: Merge Request !1003 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1003 Project:Branches: nmav/gnutls:tmp-minor-fixes to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1003 You're receiving 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 May 21 05:48:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:40 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #767: https://gitlab.com/gnutls/gnutls/issues/767 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767 You're receiving 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 May 21 05:48:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:41 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't allow keyusage Digital signature in CA certificates (#767) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #767: https://gitlab.com/gnutls/gnutls/issues/767 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/767 You're receiving 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 May 21 05:48:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 03:48:40 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PROFILE_FUTURE missing (#770) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #770: https://gitlab.com/gnutls/gnutls/issues/770 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/770 You're receiving 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 May 21 08:28:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 06:28:53 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) References: Message-ID: New Merge Request !1004 https://gitlab.com/gnutls/gnutls/merge_requests/1004 Branches: tmp-remove-unused-flag to master Author: Nikos Mavrogiannopoulos Assignees: `gnutls_certificate_verify_flags` comparisons in lib/pubkey.c against deprecated `OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA` define (previously `GNUTLS_PUBKEY_VERIFY_FLAG_TLS1_RSA`) break functions `gnutls_pubkey_verify_data2` and `gnutls_pubkey_verify_hash2` when `GNUTLS_VERIFY_DISABLE_CA_SIGN` `gnutls_certificate_verify_flags` is set. The supplementary comparison against `OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA` has been removed in favor of the exclusive comparison against `GNUTLS_VERIFY_USE_TLS1_RSA` `gnutls_certificate_verify_flags` due to the old value no longer being referenced in internal gnutls calling of these two functions and also having been replaced by the latter flag. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] 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/1004 You're receiving 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 May 21 08:29:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 06:29:38 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!981) In-Reply-To: References: Message-ID: Replaced by !1004 1004 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/981#note_172569226 You're receiving 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 May 21 08:29:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 06:29:39 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!981) In-Reply-To: References: Message-ID: Merge Request !981 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/981 Project:Branches: kmiller/gnutls:master to gnutls/gnutls:master Author: Kenneth J_ Miller Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/981 You're receiving 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 May 21 08:36:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 06:36:32 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.8 (Mar 28, 2019?May 28, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/21 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1004 You're receiving 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 May 21 08:56:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 06:56:51 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/libgnutls.map: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172576414 > global: > gnutls_prf_early; > gnutls_record_set_max_recv_size; > + gnutls_dh_params_import_raw3; > + gnutls_ffdhe_2048_group_q; Let's add these in `tests/suite/prime-check.c` to catch any potential typos or incorrect updates in the future. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172576414 You're receiving 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 May 21 11:29:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 09:29:11 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Applying `warn_unused_result` found another unchecked function call. The `nonnull` attributes only helps with obvious NULL params. Static analyzers may improve their results as well. At least for internal functions we should apply those attributes more widely, WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_172640900 You're receiving 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 May 21 12:42:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 10:42:33 +0000 Subject: [gnutls-devel] libtasn1 | Make use of const variant of asn1_node (!9) References: Message-ID: New Merge Request !9 https://gitlab.com/gnutls/libtasn1/merge_requests/9 Branches: tmp-asn1_node_const to master Author: Tim R?hsen Assignees: Add type 'asn1_node_const' and apply it to function params where possible. This allows https://gitlab.com/gnutls/gnutls/merge_requests/1000 to be worked on easier. ## Checklist * [x] Code modified for feature ## Reviewer's checklist: * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent with other code * [ ] 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/libtasn1/merge_requests/9 You're receiving 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 May 21 12:44:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 10:44:13 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: MR for libtasn1 has been made. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172687061 You're receiving 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 May 21 12:54:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 10:54:47 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: I'll try to check the TLS part as soon. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172699669 You're receiving 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 May 21 13:44:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 11:44:10 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Yes, great idea to start with libtasn API. I can update this change to have it ready when libtasn is ready. But I have some concerns about change to `asn1_find_node` function signature in the linked MR. It takes const arg now, and returns non-const result. In C++ usually there are 2 overloads for such `find`/`iterator` functions in std containers: one operates on const container and returns const result, another operates on non-const container and returns non-const result. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172727466 You're receiving 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 May 21 14:22:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 12:22:54 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Reassigned Merge Request 990 https://gitlab.com/gnutls/gnutls/merge_requests/990 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990 You're receiving 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 May 21 14:24:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 12:24:36 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: The tls1.3 part looks good to me -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172753798 You're receiving 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 May 21 14:30:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 12:30:39 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Ok I'll try to add the prime-check.c stuff today. Meanwhile the pipeline shows green but I got a failure notice via email, is this a known issue with our CI ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172757561 You're receiving 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 May 21 14:59:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 12:59:35 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Ok. Let me know once the tls1.2 part is there too, and I'll give it a final review. It had a failure but I restarted the job and passed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172775400 You're receiving 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 May 21 15:26:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 13:26:06 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: > But I have some concerns about change to asn1_find_node function signature in the linked MR. 'const' is a promise to the caller that the callee doesn't change it's contents (resp. the memory region a pointer points to) via this pointer. And in this it is absolutely fine to take a const argument and return a non-const, even if they both have identical values. The caller knows 'callee didn't change my data', but also the caller should be able to decide on it's own if the returning pointer is const or not. To avoid forcing the caller to use a cast, `asn1_find_node` returns a non-const value. The promise has been fullfilled by callee and after returning there is no promise any more. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172795892 You're receiving 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 May 21 15:41:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 13:41:54 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Added Q testing prime-check.c -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172805165 You're receiving 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 May 21 16:44:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 14:44:47 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Merge Request !1000 was reopened by Aleksei Nikiforov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1000 Project:Branches: darktemplarbasealt/gnutls:mark_const to gnutls/gnutls:master Author: Aleksei Nikiforov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000 You're receiving 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 May 21 16:57:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 14:57:29 +0000 Subject: [gnutls-devel] GnuTLS | Mark arguments of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Sorry for my lack of attention. It looks like `gnutls_datum_t` is a typedef to a struct, while `gnutls_x509_crt_t` is a typedef to pointer at the moment. Due to that, `const gnutls_datum_t*` is a pointer to const data, while `const gnutls_x509_crt_t` is a const pointer to data. That explains lack of expected warnings (const pointer is just copied as non-const pointer for function argument when needed) and makes this change more trivial (there is no point in marking such pointers as const, it's a copy anyway). Changes to libtasn are not required, as shouldn't be required changes to any other functions since they're not called with provided `const gnutls_datum_t*`. It should be enough to change `gnutls_datum_t * der` to `const gnutls_datum_t * der`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172848217 You're receiving 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 May 21 18:41:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 16:41:46 +0000 Subject: [gnutls-devel] GnuTLS | Mark second argument of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Uhg, that is hard-to-recognize issue with typedef'ing pointers. A good reason not to do so. gcc -Wall shows it: ``` #include #include typedef char *str; typedef const char *str_const; int main(void) { str s1 = strdup("a"); str_const s2 = strdup("b"); const str s3 = strdup("c"); // same as 'str const s3' *s1 = 'x'; // OK *s2 = 'y'; // error *s3 = 'z'; // OK s3 = NULL; // error, s3 is 'char * const' not a 'const char *' return 0; } ``` That means we need an extra typedef to make use of 'const' for typedef'ed pointers. Ugly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000#note_172906659 You're receiving 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 May 21 21:49:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 19:49:49 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: @nmav PTAL -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_172996154 You're receiving 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 May 21 21:51:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 19:51:29 +0000 Subject: [gnutls-devel] GnuTLS | Mark second argument of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Merge Request !1000 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1000 Project:Branches: darktemplarbasealt/gnutls:mark_const to gnutls/gnutls:master Author: Aleksei Nikiforov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000 You're receiving 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 May 21 21:52:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 21 May 2019 19:52:09 +0000 Subject: [gnutls-devel] GnuTLS | Mark second argument of function gnutls_x509_crt_equals2 as const (!1000) In-Reply-To: References: Message-ID: Merge Request !1000 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1000 Project:Branches: darktemplarbasealt/gnutls:mark_const to gnutls/gnutls:master Author: Aleksei Nikiforov Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1000 You're receiving 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 May 22 10:30:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 08:30:24 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: LGTM so far. Is it intentional that the tls1.2 part (for rfc7919 primes) is not included? Seeing the patch for tls1.3 that part seems easy as well (_gnutls_proc_dh_common_server_kx -> client side, and _gnutls_figure_dh_params -> server side). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173137222 You're receiving 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 May 22 10:47:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 08:47:04 +0000 Subject: [gnutls-devel] GnuTLS | Fix handling of malformed KeyUpdate messages (!1005) References: Message-ID: New Merge Request !1005 https://gitlab.com/gnutls/gnutls/merge_requests/1005 Branches: tmp-keyupdate-fixes to master Author: Daiki Ueno Assignees: This doesn't include any tests so far, waiting for [the tlsfuzzer PR](https://github.com/tomato42/tlsfuzzer/pull/501) getting merged, with a modification to tolerate the delayed KeyUpdate reply (see (2) in #699). Fixes #699. ## 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/1005 You're receiving 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 May 22 12:07:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 10:07:14 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) References: Message-ID: New Merge Request !1006 https://gitlab.com/gnutls/gnutls/merge_requests/1006 Branches: tmp-small-records to master Author: Daiki Ueno Assignees: There is a mismatch in the lower limit of record sizes in RFC 8449 (64) and our default (512). If the server advertises a smaller limit than our default, the client has no way to keep communicating with the server. This patch adds a new priority string option %ALLOW_SMALL_RECORDS to set the limit to 64. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [x] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] 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/1006 You're receiving 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 May 22 12:13:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 10:13:45 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) In-Reply-To: References: Message-ID: Merge Request !1004 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1004 Branches: tmp-remove-unused-flag to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1004 You're receiving 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 May 22 12:14:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 10:14:20 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) In-Reply-To: References: Message-ID: Looks good, not sure why `tls13/prf-early.sh` fails but it shouldn't be related to this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1004#note_173198413 You're receiving 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 May 22 12:16:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 10:16:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls server should not negotiate TLS 1.3 if the private key from PKCS#11 does not support RSA-PSS nor raw-RSA (#731) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #731: https://gitlab.com/gnutls/gnutls/issues/731 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/731 You're receiving 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 May 22 12:16:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 10:16:55 +0000 Subject: [gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987) In-Reply-To: References: Message-ID: Merge Request !987 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/987 Branches: tmp-privkey-tls13 to master Author: Daiki Ueno Assignee: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987 You're receiving 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 May 22 13:07:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 11:07:18 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: Merge Request !1006 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1006 Branches: tmp-small-records to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006 You're receiving 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 May 22 17:02:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 15:02:32 +0000 Subject: [gnutls-devel] libtasn1 | Version numbers for libtasn1.h (#7) References: Message-ID: New Issue was created. Issue 7: https://gitlab.com/gnutls/libtasn1/issues/7 Author: Tim R?hsen Assignees: ## Description of problem: It's not easy to check for a certain version of libtasn1.h since the only version information is ``` #define ASN1_VERSION "4.13" ``` How to check for major/minor via C preprocessor (`#if ...`) ? ## Version of libtasn1 used: 4.13 ## Suggestion Use the same standards mechanism as other libraries do, e.g. gnutls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/7 You're receiving 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 May 22 17:10:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 15:10:15 +0000 Subject: [gnutls-devel] GnuTLS | Add const to function arguments in lib/x509 (!1007) References: Message-ID: New Merge Request !1007 https://gitlab.com/gnutls/gnutls/merge_requests/1007 Branches: tmp-more-const-1 to master Author: Tim R?hsen Assignees: Adding const attribute to several functions params, for functions defined in lib/x509/. ## 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/1007 You're receiving 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 May 22 19:38:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 17:38:08 +0000 Subject: [gnutls-devel] GnuTLS | Add const to function arguments in lib/x509 (!1007) In-Reply-To: References: Message-ID: @nmav The ABI checker complains when adding `const` through a typedef. I think that is over-pedantic. What can we do ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1007#note_173401298 You're receiving 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 May 22 19:55:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 17:55:24 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: I am not sure how to handle the case where we do not have Q and we are in FIPS mode. Is it ok to just have the DH exchange fail? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173405592 You're receiving 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 May 22 20:26:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 18:26:18 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Hi Simo, > I am not sure how to handle the case where we do not have Q and we are in > FIPS mode. Is it ok to just have the DH exchange fail? If the P is a Sophie-Germain prime, you must obtain Q and perform the test. If you do not have a Sophie-Germain prime and do not have Q, you can ignore the test. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173414259 You're receiving 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 May 22 21:50:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 22 May 2019 19:50:07 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Ok, added code to handle passing down Q also for other pre-TLS1.3 FFDHE handling functions -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173433662 You're receiving 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 May 23 06:11:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 04:11:17 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1004#note_173519897 You're receiving 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 May 23 06:11:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 04:11:19 +0000 Subject: [gnutls-devel] GnuTLS | pubkey: remove deprecated OLD_PUBKEY_VERIFY_FLAG_TLS1_RSA (!1004) In-Reply-To: References: Message-ID: Merge Request !1004 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1004 Branches: tmp-remove-unused-flag to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1004 You're receiving 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 May 23 06:11:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 04:11:19 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_pubkey_verify_data2 calls fail erroneously with GNUTLS_E_INVALID_REQUEST when GNUTLS_VERIFY_DISABLE_CA_SIGN flag is set (#754) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #754: https://gitlab.com/gnutls/gnutls/issues/754 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/754 You're receiving 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 May 23 06:13:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 04:13:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: cert-tests: crl: try to infer 64-bit time using date(1) (!986) In-Reply-To: References: Message-ID: Marked it as WIP because it seems in porogress -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/986#note_173520111 You're receiving 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 May 23 10:20:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 08:20:25 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: Merge Request !1006 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1006 Branches: tmp-small-records to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006 You're receiving 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 May 23 10:21:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 08:21:00 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: Thank you for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006#note_173584210 You're receiving 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 May 23 11:05:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:05:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix handling of malformed KeyUpdate messages (!1005) In-Reply-To: References: Message-ID: Merge Request !1005 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1005 Branches: tmp-keyupdate-fixes to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1005 You're receiving 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 May 23 11:05:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:05:29 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #699: https://gitlab.com/gnutls/gnutls/issues/699 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699 You're receiving 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 May 23 11:05:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:05:29 +0000 Subject: [gnutls-devel] GnuTLS | multiple issues in handling KeyUpdate messages (#699) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #699: https://gitlab.com/gnutls/gnutls/issues/699 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/699 You're receiving 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 May 23 11:05:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:05:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix handling of malformed KeyUpdate messages (!1005) In-Reply-To: References: Message-ID: Merge Request !1005 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1005 Branches: tmp-keyupdate-fixes to master Author: Daiki Ueno Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1005 You're receiving 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 May 23 11:25:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:25:32 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: My final review: - In tests/*dh-compute.c the fail() arguments print __LINE__ and __func__ but these are already included in the output of fail() - In lib/nettle/pk.c the FIPS check is only run when `PK_DERIVE_TLS13` flag is set. That means it will not be run under TLS1.2. Maybe a new flag to indicate known parameters? - There is a typo in two of the commit messages 'paramters', and 'tLS 1.3' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173618113 You're receiving 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 May 23 11:31:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:31:24 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Checking the second point again, it seems we may not need this test at all in TLS1.2. In that case if q is passed the test will be run. Only in TLS1.3 we know that q is mandatory. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173622259 You're receiving 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 May 23 11:36:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:36:38 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: I've fixed these and pushed manually. Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173626488 You're receiving 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 May 23 11:36:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 09:36:39 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Merge Request !990 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/990 Project:Branches: simo5/gnutls:ec-dh-keys-tests to gnutls/gnutls:master Author: Simo Sorce Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990 You're receiving 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 May 23 13:03:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 11:03:17 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: Wish I could review more of your MRs. But it's often about details that I don't know about. Well, I can see if there are obvious failures, code conventions applied etc. but not if this and that algorithm is correct in regards of standards. So consider an approval from me as that ;-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006#note_173670113 You're receiving 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 May 23 14:07:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 12:07:59 +0000 Subject: [gnutls-devel] GnuTLS | DH and ECDH keys tests (!990) In-Reply-To: References: Message-ID: Thanks, about point 2, that was exactly my reasoning. The FIPs check was just an extra to protect from errors that may happen in TLS1.3 paths that would end up using an incorrect configuration, somehow (not that I see any way to it now, just future proofing). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/990#note_173698666 You're receiving 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 May 23 21:16:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:16:21 +0000 Subject: [gnutls-devel] GnuTLS | fuzzying: enable raw public keys (#687) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/687 You're receiving 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 May 23 21:16:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:16:23 +0000 Subject: [gnutls-devel] GnuTLS | fuzzying: enable raw public keys (#687) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/687 You're receiving 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 May 23 21:16:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:16:38 +0000 Subject: [gnutls-devel] GnuTLS | Unencrypted Finished msg is rejected with incorrect Alert (#643) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/643 You're receiving 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 May 23 21:16:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:16:40 +0000 Subject: [gnutls-devel] GnuTLS | Unencrypted Finished msg is rejected with incorrect Alert (#643) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/643 You're receiving 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 May 23 21:16:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:16:53 +0000 Subject: [gnutls-devel] GnuTLS | session resumption: ability to limit resumption to TLS 1.3+ connections (#477) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/477 You're receiving 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 May 23 21:17:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:17:04 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli-debug should test whether RSA key exchange is enabled (#449) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/449 You're receiving 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 May 23 21:17:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:17:14 +0000 Subject: [gnutls-devel] GnuTLS | handle OID 1.3.6.1.4.1.11129.2.4.2 (x.509 extension for certificate transparency SCTs) (#232) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/232 You're receiving 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 May 23 21:25:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:25:47 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) References: Message-ID: New Merge Request !1008 https://gitlab.com/gnutls/gnutls/merge_requests/1008 Branches: tmp-avoid-libs-in-libsvar to master Author: Nikos Mavrogiannopoulos Assignees: This ensures that libraries are linked with the programs requiring them. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature ## 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/1008 You're receiving 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 May 23 21:26:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 23 May 2019 19:26:19 +0000 Subject: [gnutls-devel] GnuTLS | Tests with RSA-PSS private_key and rsae/rsa-pss signature schemes. (#646) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/646 You're receiving 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 May 24 05:48:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 03:48:38 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) References: Message-ID: New Merge Request !1009 https://gitlab.com/gnutls/gnutls/merge_requests/1009 Branches: tmp-version-override to master Author: Nikos Mavrogiannopoulos Assignees: This allows having fixed data in the hello message involved. That required exposing the variable holding the global gnutls version number for testing. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature ## 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/1009 You're receiving 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 May 24 05:51:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 03:51:35 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) In-Reply-To: References: Message-ID: @dueno what do you think of this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1009#note_173995543 You're receiving 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 May 24 05:51:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 03:51:59 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: Reassigned Issue 735 https://gitlab.com/gnutls/gnutls/issues/735 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735 You're receiving 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 May 24 05:55:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 03:55:07 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) In-Reply-To: References: Message-ID: Looks good to me. Sorry for not catching this earlier. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1009#note_173995932 You're receiving 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 May 24 05:55:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 03:55:18 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) In-Reply-To: References: Message-ID: Merge Request !1009 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1009 Branches: tmp-version-override to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1009 You're receiving 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 May 24 06:13:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 04:13:36 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) In-Reply-To: References: Message-ID: Thanks for the review and figuring it out. That was kind of tough to catch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1009#note_173998253 You're receiving 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 May 24 07:58:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 05:58:35 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174019830 > > dnl This ensures that we link with the right library for atomic operations on Linux SPARC > AC_SEARCH_LIBS([__atomic_load_4], [atomic], [], [AC_MSG_NOTICE([Could not detect libatomic])]) > +LIBS=$ac_func_search_save_LIBS Is `ac_func_search_save_LIBS` a documented variable we can rely on? If not, I would suggest to explicitly save/restore LIBS by adding: ```sh save_LIBS=$LIBS ... AC_SEARCH_LIBS(...) ... LIBS=$save_LIBS ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174019830 You're receiving 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 May 24 08:33:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 06:33:39 +0000 Subject: [gnutls-devel] GnuTLS | tests: prf-early fixes the global version (!1009) In-Reply-To: References: Message-ID: Merge Request !1009 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1009 Branches: tmp-version-override to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1009 You're receiving 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 May 24 09:06:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 07:06:28 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174039507 > > dnl This ensures that we link with the right library for atomic operations on Linux SPARC > AC_SEARCH_LIBS([__atomic_load_4], [atomic], [], [AC_MSG_NOTICE([Could not detect libatomic])]) > +LIBS=$ac_func_search_save_LIBS I agree, it's not documented (https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Libraries.html). And using your `save_LIBS` approach is more readable and more widespread (though not not as elegant). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174039507 You're receiving 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 May 24 13:04:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 11:04:55 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on configure.ac: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174148084 > > dnl This ensures that we link with the right library for atomic operations on Linux SPARC > AC_SEARCH_LIBS([__atomic_load_4], [atomic], [], [AC_MSG_NOTICE([Could not detect libatomic])]) > +LIBS=$ac_func_search_save_LIBS Thanks updated. I've also added a check in a run that LIBS is empty, though that was already the case in Linux. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008#note_174148084 You're receiving 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 May 24 13:04:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 11:04:56 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: All discussions on Merge Request !1008 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/1008 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008 You're receiving 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 May 24 14:21:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 12:21:42 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: Merge Request !1008 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1008 Branches: tmp-avoid-libs-in-libsvar to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008 You're receiving 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 May 24 16:12:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:12:16 +0000 Subject: [gnutls-devel] GnuTLS | Do not add libraries in the global LIBS in configure (!1008) In-Reply-To: References: Message-ID: Merge Request !1008 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1008 Branches: tmp-avoid-libs-in-libsvar to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1008 You're receiving 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 May 24 16:12:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:12:16 +0000 Subject: [gnutls-devel] GnuTLS | Unwanted -lunistring leak to global LIBS in configure (#735) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #735: https://gitlab.com/gnutls/gnutls/issues/735 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/735 You're receiving 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 May 24 16:14:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:14:01 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: I think it is a good idea. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174244565 You're receiving 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 May 24 16:43:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:43:31 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/srp.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174267315 > unsigned int salt_length) > { > _gnutls_free_datum(&cred->fake_salt_seed); > - _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); > + if (_gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size) < 0) { Hmmm, with that change here, doesn't it mean that on failure there is no error indication an the fake_salt_seed is now uninitialized? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174267315 You're receiving 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 May 24 16:46:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:46:24 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/session.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174268443 > > if (session->internals.resumption_data.data != NULL) > gnutls_free(session->internals.resumption_data.data); > - _gnutls_set_datum(&session->internals.resumption_data, session_data, session_data_size); > + ret = _gnutls_set_datum(&session->internals.resumption_data, session_data, session_data_size); That's a behavioral change, but may be ok. This makes setting the session resumption data mandatory (i.e., this function will fail if allocation will fail). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174268443 You're receiving 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 May 24 16:47:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 14:47:50 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: I don't think we should merge it for this release as it may have unintended consequences (places where a failure was checked but not acted upon because of the implicit assumption of initialization). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174269075 You're receiving 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 May 24 17:09:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 15:09:09 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/session.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174277409 > > if (session->internals.resumption_data.data != NULL) > gnutls_free(session->internals.resumption_data.data); > - _gnutls_set_datum(&session->internals.resumption_data, session_data, session_data_size); > + ret = _gnutls_set_datum(&session->internals.resumption_data, session_data, session_data_size); The function also returns error in other cases. So I think it should really be ok return error in case of allocation failure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174277409 You're receiving 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 May 24 17:14:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 15:14:38 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: If in doubt, leave it out of this release. You know the srp code better - is there anything we can do to provide consistent behavior ? If not, we should return an int (error code) in the long term. Existing code should still work without changes (except we add attribute `warn_unused_result` - in this case exisiting code will see a warning). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174279286 You're receiving 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 May 24 17:21:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 15:21:20 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/srp.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174281630 > unsigned int salt_length) > { > _gnutls_free_datum(&cred->fake_salt_seed); > - _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); > + if (_gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size) < 0) { Would it be ok to set ``` cred->fake_salt_seed.data = NULL; cred->fake_salt_seed.size = 0; cred->fake_salt_length = 0; ``` ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174281630 You're receiving 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 May 24 20:01:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 18:01:13 +0000 Subject: [gnutls-devel] GnuTLS | support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Ander Juaristi commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174340914 > } else if (pskcred && > psk.ob_ticket_age == 0 && > psk.identity.size > 0 && psk.identity.size <= MAX_USERNAME_SIZE) { > - /* _gnutls_psk_pwd_find_entry() expects 0-terminated identities */ > - char identity_str[MAX_USERNAME_SIZE + 1]; > - > prf = pskcred->binder_algo; > > - memcpy(identity_str, psk.identity.data, psk.identity.size); > - identity_str[psk.identity.size] = 0; > - > /* this fails only on configuration errors; as such we always > * return its error code in that case */ > - ret = _gnutls_psk_pwd_find_entry(session, identity_str, &key); > + ret = _gnutls_psk_pwd_find_entry(session, (const char *) psk.identity.data, psk.identity.size, &key); Yes, because data is an `unsigned char *`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174340914 You're receiving 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 May 24 20:26:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 24 May 2019 18:26:04 +0000 Subject: [gnutls-devel] GnuTLS | support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Ander Juaristi commented on a discussion on lib/psk.c: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174345898 > + * The callback function should return 0 on success. > + * -1 indicates an error. > + **/ > +void > +gnutls_psk_set_client_credentials_function2(gnutls_psk_client_credentials_t cred, > + gnutls_psk_client_credentials_function2 *func) > +{ > + cred->get_function.cb2 = func; > + cred->function_in_use = 2; > +} > + > + > +static int > +username_has_embedded_nulls(psk_auth_info_t info) > +{ > + for (uint16_t i = 0; i < info->len; i++) { Where is it defined? I can't find it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174345898 You're receiving 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 May 25 17:16:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 15:16:57 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) References: Message-ID: New Issue was created. Issue 772: https://gitlab.com/gnutls/gnutls/issues/772 Author: Nikos Mavrogiannopoulos Assignees: When --enable-local-libopts is given to configure gnutls still calls autogen to generate the sources in `src/`. That's creating several compatibility issues as our included libopts cannot work with any arbitrary autogen version. That seems a regression since 3.6.5. https://github.com/openwrt/packages/issues/8129 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772 You're receiving 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 May 25 17:30:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 15:30:45 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: The question is: How can we get rid of the libopts drama once and forever ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174495469 You're receiving 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 May 25 18:01:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 16:01:21 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: We could e.g. separate documentation of the tools and option parsing. Documentation should IMO be markdown, it can be converted into man pages, .texi and from there to arbitrarily anything. The option parsing needs parsing routines (one for all) and each tool has a list of options. It's easy to maintain / extend. As many projects, we did it in Wget2 with success. If there is agreement, I would volunteer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174497481 You're receiving 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 May 25 21:09:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:09:26 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Adapted the parsing code from wget2: - one less dependency - stripped binary is even 1k smaller (named `psk2tool`): ``` -rwxr-xr-x 1 tim tim 18784 Mai 25 21:04 psk2tool -rwxr-xr-x 1 tim tim 19832 Mai 25 21:04 psktool ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174526067 You're receiving 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 May 25 21:19:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:19:20 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Libopts/autogen is used for the following reasons: 1. generation of manpages /texinfo of tools options and examples 2. tools in src/ use it to parse command line 3. certtool uses it to parse templates -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174526624 You're receiving 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 May 25 21:23:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:23:34 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: It is quite a big project to do all of these, and a strategy could be to take it piece by piece. There are 3 tasks here which we can create issues for them, and address them over time. I have a WIP MR to bring `inih` parser to the gnutls lib, so (3) could be solved using inih as well (another project I've replaced with it quite successfully) whenever/if that patch gets in. I could take that? What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174526883 You're receiving 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 May 25 21:41:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:41:20 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Would be good if you take care of (3) (I have no idea of it). (2) now is just some tedious work, the base work is done. (1) The quick way would be to take the man pages, and add them to the repo as markdown files. We can use pandoc to convert those to man pages and texinfo (we do so at wget2). Disadvantage: we have too places with the options that might go out of sync (tool and markdown). Another option would be to generate the markdown pages using a template + the option output of the tools (--help). I could write a script for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174527951 You're receiving 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 May 25 21:46:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:46:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Do not regenerate autogen files is --enable-local-libopts is given (!1010) References: Message-ID: New Merge Request !1010 https://gitlab.com/gnutls/gnutls/merge_requests/1010 Branches: tmp-fix-libopts to master Author: Nikos Mavrogiannopoulos Assignees: This addresses issue on installed systems which have autogen but use --enable-local-libopts. In these systems if the installed autogen would not match the local libopts library version compilation would fail because the auto-generated files depend on the corresponding to autogen version libopts internals. That however requires us to ship the corresponding files which match our included libopts library. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests (not really; a test was added directly in .gitlab-ci.yml) ## 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/1010 You're receiving 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 May 25 21:48:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:48:24 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Let me create a milestone with these three tasks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174528449 You're receiving 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 May 25 21:54:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:54:27 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Reassigned Issue 772 https://gitlab.com/gnutls/gnutls/issues/772 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772 You're receiving 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 May 25 21:59:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 19:59:21 +0000 Subject: [gnutls-devel] GnuTLS | gnutls does not depend on autogen for the generation of manpages/texinfo documentation (#773) References: Message-ID: New Issue was created. Issue 773: https://gitlab.com/gnutls/gnutls/issues/773 Author: Nikos Mavrogiannopoulos Assignees: This is about avoiding to use of autogen for the generation of the manpages and texinfo documentation of the tools in src/. The tricky part is that the use of autogen eliminates the risk of out-of-date documentation of these tools, as the documentation is auto-generated from the definitions. Any replacement should not re-introduce that risk. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/773 You're receiving 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 May 25 22:06:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 20:06:57 +0000 Subject: [gnutls-devel] GnuTLS | certtool should not use libopts to parse template files (#774) References: Message-ID: New Issue was created. Issue 774: https://gitlab.com/gnutls/gnutls/issues/774 Author: Nikos Mavrogiannopoulos Assignees: certtool uses libopts to parse template files and as we are disentangling from it, certtool should use something simpler and more efficient. In particular, the certtool template format is a `key = value` format without sections, and pretty much any .ini file handler would do. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/774 You're receiving 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 May 25 22:09:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 20:09:29 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Done: https://gitlab.com/gnutls/gnutls/milestones/23 I'll however, try to address this issue for the next release with autogen. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174529775 You're receiving 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 May 25 22:08:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 25 May 2019 20:08:17 +0000 Subject: [gnutls-devel] GnuTLS | tools in src/ should not use libopts for parsing cmd line options (#775) References: Message-ID: New Issue was created. Issue 775: https://gitlab.com/gnutls/gnutls/issues/775 Author: Nikos Mavrogiannopoulos Assignees: The tools in `src/` use libopts to parse the command line options and as we are disentangling from it, certtool should use something simpler. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/775 You're receiving 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 May 26 21:54:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 26 May 2019 19:54:24 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) References: Message-ID: New Merge Request !1011 https://gitlab.com/gnutls/gnutls/merge_requests/1011 Branches: tmp-releases to master Author: Nikos Mavrogiannopoulos Assignees: This adds a file to document the policy on releases based on the discussions taken place in the last face to face meeting. https://gitlab.com/gnutls/gnutls/wikis/face2face-meeting-fosdem2019 ## Checklist * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 26 22:16:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 26 May 2019 20:16:27 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: I pushed a branch 'tmp-remove-libopts' that adds the code for (1) and (2). It generates src/psk2tool (copy of psktool but with the new parsing code) and docs/manpages/psk2tool.1, docs/manpages/psk2tool.texi and docs/manpages/psk2tool.info via pandoc. Just a first PoC. Feel free to review / comment. When we agree upon that as a general approach, I start fine-tuning and moving psk2tool -> psktool, then work on the other tools. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174650504 You're receiving 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 May 26 22:35:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 26 May 2019 20:35:36 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Would you like to create an MR to your repo for easier review? btw, why a new tool rather than the same tool? Also I think we should move this discussion to #775 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174652339 You're receiving 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 May 27 06:47:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 04:47:07 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/772#note_174696139 Is there any reason not to use help2man for (1)? I find Haskell dependency from pandoc rather problematic, though it's not a hard-dependency. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174696139 You're receiving 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 May 27 09:49:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 07:49:23 +0000 Subject: [gnutls-devel] GnuTLS | git clone error on ubuntu 19.04 (#769) In-Reply-To: References: Message-ID: I've tried but it doesn't work. The problem, on my opinion, is with my firewall base on armbian/debian as I posted. I'm tring (during little free time) to find the differences in configuration between this one and the new based on ubuntu. thanks -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/769#note_174738817 You're receiving 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 May 27 09:49:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 07:49:45 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/772#note_174738928 We also need .texi output. If help2man can do it (not sure what -p does), we should definitely consider it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772#note_174738928 You're receiving 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 May 27 10:03:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 08:03:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) References: Message-ID: New Merge Request !1012 https://gitlab.com/gnutls/gnutls/merge_requests/1012 Branches: tmp-remove-libopts to master Author: Tim R?hsen Assignees: PoC to replace libopts dependency. `src/psk2.c` is a copy of `src/psk.c` which uses the new `src/options.c`. `doc/manpages/Makefile.am` generates man, texi, info from `psk2tool` and `psk2tool.md.in` (a markdown template). Can we replace `pandoc` by something else with less dependencies (e.g. help2man) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012 You're receiving 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 May 27 10:04:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 08:04:28 +0000 Subject: [gnutls-devel] GnuTLS | tools in src/ should not use libopts for parsing cmd line options (#775) In-Reply-To: References: Message-ID: MR !1012 created for first glimpse review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/775#note_174745040 You're receiving 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 May 27 10:15:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 08:15:07 +0000 Subject: [gnutls-devel] GnuTLS | Certtool doesn't add CDP from the template (#765) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/765 You're receiving 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 May 27 11:21:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 09:21:52 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Now set `cred->fake_salt_length = 0` in case of an error. `cred->fake_salt_seed` is in this case initialized to `{ NULL, 0 }` (from the call to `_gnutls_free_datum()`. So in case of an error, everything is initialized `as good as possible` - plus we see a log entry via `gnutls_assert()`. I think this is the best we can do without changing the ABI (return type void -> int). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174778438 You're receiving 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 May 27 13:45:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 11:45:19 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: @rockdaboot what do you think about it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_174835478 You're receiving 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 May 27 14:28:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 12:28:14 +0000 Subject: [gnutls-devel] GnuTLS | support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/psk.c: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174851887 > + * The callback function should return 0 on success. > + * -1 indicates an error. > + **/ > +void > +gnutls_psk_set_client_credentials_function2(gnutls_psk_client_credentials_t cred, > + gnutls_psk_client_credentials_function2 *func) > +{ > + cred->get_function.cb2 = func; > + cred->function_in_use = 2; > +} > + > + > +static int > +username_has_embedded_nulls(psk_auth_info_t info) > +{ > + for (uint16_t i = 0; i < info->len; i++) { It seems it is in `x509/email-verify.c` and duplicated in `x509/hostname-verify.c`. What about moving it to str.h and sharing it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174851887 You're receiving 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 May 27 14:29:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 12:29:25 +0000 Subject: [gnutls-devel] GnuTLS | support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/pre_shared_key.c: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174852416 > } else if (pskcred && > psk.ob_ticket_age == 0 && > psk.identity.size > 0 && psk.identity.size <= MAX_USERNAME_SIZE) { > - /* _gnutls_psk_pwd_find_entry() expects 0-terminated identities */ > - char identity_str[MAX_USERNAME_SIZE + 1]; > - > prf = pskcred->binder_algo; > > - memcpy(identity_str, psk.identity.data, psk.identity.size); > - identity_str[psk.identity.size] = 0; > - > /* this fails only on configuration errors; as such we always > * return its error code in that case */ > - ret = _gnutls_psk_pwd_find_entry(session, identity_str, &key); > + ret = _gnutls_psk_pwd_find_entry(session, (const char *) psk.identity.data, psk.identity.size, &key); Wouldn't then a cast to `char *` be sufficient? The const seems unnecessary -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_174852416 You're receiving 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 May 27 14:45:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 12:45:39 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: For this particular problem what about eliminating the allocation completely? It seems unnecessary and a patch is attached. Nevertheless, in the general change, are you confident with this version that other uses do not rely on the old behavior? [patch.txt](/uploads/70ddef3fbdacda125d44464545f1c10d/patch.txt) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174858952 You're receiving 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 May 27 15:09:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 13:09:38 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: > For this particular problem what about eliminating the allocation completely? It seems unnecessary and a patch is attached. That is good. > Nevertheless, in the general change, are you confident with this version that other uses do not rely on the old behavior? How confident can you be ? If someone relies on undocumented side-effects of a function, then ?\_(?)_/?. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174870499 You're receiving 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 May 27 15:19:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 13:19:56 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Replaced my srp.c commit with your patch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174875942 You're receiving 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 May 27 16:42:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 27 May 2019 14:42:44 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Ouch, I forgot about the commit check - @nmav are you going to merge the branch / MR manually ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_174917340 You're receiving 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 May 28 06:43:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 04:43:29 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: It seems that we will have to postpone this for 3.6.9 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175111297 You're receiving 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 May 28 06:43:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 04:43:33 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010 You're receiving 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 May 28 06:43:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 04:43:46 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772 You're receiving 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 May 28 07:40:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 07:40:09 +0200 Subject: [gnutls-devel] gnutls 3.6.8 Message-ID: Hello, I've just released gnutls 3.6.8. This is a bug fix release on the stable 3.6.x branch. I'd like to thank everyone who contributed in this release: Aleksei Nikiforov, Alon Bar-Lev, Andreas Metzler, Bernhard M. Wiedemann, Daiki Ueno, Daniel Schaefer, Dmitry Eremin-Solenikov, Elta Koepp, Kenneth J. Miller, Maciej S. Szmigiero, Marius Bakke Simo Sorce and Tim R?hsen. The detailed list of changes follows; they can be seen in more detail in our milestone tracker: https://gitlab.com/gnutls/gnutls/milestones/21 Changes ======= * Version 3.6.8 (released 2019-05-28) ** libgnutls: Added gnutls_prf_early() function to retrieve early keying material (#329) ** libgnutls: Added support for AES-XTS cipher (#354) ** libgnutls: Fix calculation of Streebog digests (incorrect carry operation in 512 bit addition) ** libgnutls: During Diffie-Hellman operations in TLS, verify that the peer's public key is on the right subgroup (y^q=1 mod p), when q is available (under TLS 1.3 and under earlier versions when RFC7919 parameters are used). ** libgnutls: the gnutls_srp_set_server_credentials_function can now be used with the 8192 parameters as well (#995). ** libgnutls: Fixed bug preventing the use of gnutls_pubkey_verify_data2() and gnutls_pubkey_verify_hash2() with the GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754) ** libgnutls: The priority string option %ALLOW_SMALL_RECORDS was added to allow clients to communicate with the server advertising smaller limits than 512 ** libgnutls: Apply STD3 ASCII rules in gnutls_idna_map() to prevent hostname/domain crafting via IDNA conversion (#720) ** certtool: allow the digital signature key usage flag in CA certificates. Previously certtool would ignore this flag for CA certificates even if specified (#767) ** gnutls-cli/serv: added the --keymatexport and --keymatexportsize options. These allow testing the RFC5705 using these tools. ** API and ABI modifications: gnutls_prf_early: Added gnutls_record_set_max_recv_size: Added gnutls_dh_params_import_raw3: Added gnutls_ffdhe_2048_group_q: Added gnutls_ffdhe_3072_group_q: Added gnutls_ffdhe_4096_group_q: Added gnutls_ffdhe_6144_group_q: Added gnutls_ffdhe_8192_group_q: Added Getting the Software ==================== GnuTLS may be downloaded directly from ;;. A list of GnuTLS mirrors can be found at ;;. Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.8.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.8.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From gnutls-devel at lists.gnutls.org Tue May 28 11:38:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 09:38:06 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: >> Nevertheless, in the general change, are you confident with this version that other uses do not rely on the old behavior? > How confident can you be ? If someone relies on undocumented side-effects of a function, then ?\\*(?)*/?. I'd say that the function itself is the documentation for internal APIs, so I see it as changing a "documented" behavior. If there is code which relied on the behavior of always initializing the output, we may be adding new memory safety issues. I'd need your help to understand the balance between the risk of introducing a new issue vs the value of the change. Is your objection on the behavior of the function the fact that a `set()` function should not modify its output on failure, would a rename or explicit documentation about its behavior address it? Nevertheless, I find all the other changes in this patch set, as very useful. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175214754 You're receiving 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 May 28 15:28:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 13:28:27 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: > If there is code which relied on the behavior of always initializing the output, we may be adding new memory safety issues. All calls to `_gnutls_set_datum` and `_gnutls_set_strdatum` now check their return value and fail out on error. I also manually skimmed through the places where we call one of those functions. LGTM to me. `warn_unused_result` immediately warns us if we introduce an unchecked call in the future. `nonnull((1))` triggers an error on clang's build-scan if the first argument could be NULL. `_gnutls_set_strdatum` also allows `data == NULL` as long as the `data_size` argument is 0. So I would say, we are as save as we can be. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175346099 You're receiving 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 May 28 16:49:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 14:49:18 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: I've amended my previous patch, to avoid the `assert()`. > `_gnutls_set_strdatum` also allows `data == NULL` as long as the `data_size` argument is 0. I'll comment inline. > `warn_unused_result` immediately warns us if we introduce an unchecked call in the future. > `nonnull((1))` triggers an error on clang's build-scan if the first argument could be NULL. My concern was a function calling `set()`, then acting assuming the value is initialized to either `NULL` or something else irrespective of failure or success. > All calls to `_gnutls_set_datum` and `_gnutls_set_strdatum` now check their return value and fail out on error. I also manually skimmed through the places where we call one of those functions. LGTM. Thank you for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175390188 You're receiving 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 May 28 16:53:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 14:53:34 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1002 was reviewed by Nikos Mavrogiannopoulos -- Nikos Mavrogiannopoulos started a new discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175392191 > - return 0; > - } > + if (data == NULL) Is that change based on your investigation that no null can be provided to it? It seems to change this function's semantics. btw. `GNUTLS_E_INVALID_REQUEST` is sent by other functions on invalid input. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002 You're receiving 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 May 28 17:23:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 15:23:40 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/datum.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175405708 > > /* ensures that the data set are null-terminated > * The function always returns an allocated string in @dat on success. > + * On error, @dat is not changed. > */ > int > _gnutls_set_strdatum(gnutls_datum_t * dat, const void *data, size_t data_size) > { > - if (data_size == 0 || data == NULL) { > - dat->data = gnutls_calloc(1, 1); > - dat->size = 0; > - return 0; > - } > + if (data == NULL) `data` comes from sources that are not trackable, e.g. by build-scan. Thus, using a `nonnull` attribute would lead to warnings that you can't easily work around. Also, `nonnull` will remove checks against NULL when optimization is on. The only way currently is to check data against NULL and not use `nonnull`. We *could* remove that check if `data_size` is 0 and `data` is NULL. Not sure if that is guaranteed everywhere (it should, though). Your above comments made me nervous about that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175405708 You're receiving 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 May 28 23:16:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 21:16:37 +0000 Subject: [gnutls-devel] GnuTLS | Name Constraints applied to intermediate CA CN because CA certificate does not have Extended key usage (2.5.29.37) (#776) References: Message-ID: New Issue was created. Issue 776: https://gitlab.com/gnutls/gnutls/issues/776 Author: Luiz Angelo Daros de Luca Assignees: ## Description of problem: gnutls rejects intermediate CA when root CA has a name constraint and intermediate CA does not have Extended key usage (2.5.29.37) pidgin-2.13.0 cannot validate XMPP server certificate and does not connect ## Version of gnutls used: 3.6.7 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) OpenSUSE Tumbleweed ## How reproducible: I have an internal PKI infrastructure like this: Root CA Intermediate CA Servers certificates My Root CA have some name constraints that limit Servers certificate to only domains under our control. We have been using this setup for some years now without issues. However, pidgin always failed to authenticate xmpp certificates. pidgin has x509_certificate_signed_by to test a certificate validity. It will be called twice: x509_certificate_signed_by("server_certificate", "Intermediate CA") x509_certificate_signed_by("Intermediate CA", "Root CA") In that pidgin function, it calls gnutls_x509_crt_verify (a _gnutls_verify_crt_status wrapper) with the comment "Now, check the signature". _gnutls_verify_crt_status eventually calls "verify_crt()" with the comment "Verify the last certificate in the certificate path" One of the tests is: gnutls_x509_name_constraints_check_crt(vparams->nc, GNUTLS_SAN_DNSNAME, cert); Which will test name constraints agains DNSNAME (subjetAltName). However, if no subjetAltName was found, it will also test against CN but only "verify the name constraints against the CN, if the certificate is not a CA. We do this check only on certificates marked as WWW server, because that's where the CN check is only performed.". It checks if it is a "server certificate" and not a CA using _gnutls_check_key_purpose that calls gnutls_x509_crt_get_key_purpose_oid. gnutls_x509_crt_get_key_purpose_oid simply bails out if there is no "2.5.29.37" extension and it assumes that certificate can be used by "any purpose". Well, my Intermediate CA has these key usage (2.5.29.15): "Certificate Sign, CRL Sign" and Basic Constraint CA:TRUE, but not Extended key usage (2.5.29.37). My Intermediate CA is considered as a "Web Server". As it normally happens, my Intermediate CA CN will not be a valid DNS name that satisfy Root CA DNS Name constraint. "Intermediate CA" certificate is rejected and also "Server certificate". Normally a DNS name constraint should not be tested against a CN that does not look like a FQDN. Also, I might have missed something but it looks like name constraint are tested only against issuer name constraint. However, name constraint should be tested all way down the chain, testing "Server Certificate" names also against Root CA name constraints: ## Actual results: Client rejects server certificate blaming that "Intermediate CA" certificate is invalid ## Expected results: As any other SSL lib tested, certificate should be accepted. Also, gnutls-cli does accept that certificate. Is pidgin using something that it shouldn't? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/776 You're receiving 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 May 28 23:24:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 28 May 2019 21:24:17 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli cannot specify server name while doing xmpp starttls (#777) References: Message-ID: New Issue was created. Issue 777: https://gitlab.com/gnutls/gnutls/issues/777 Author: Luiz Angelo Daros de Luca Assignees: ## Description of the feature: XMPP starttls sends the servername before requesting STARTTLS. However, the server might reject that request if the XMPP domains does not match (/host-unknown). This happens specially when "IN SRV" entries are in use for XMPP. ## Applications that this feature may be relevant to: `gnutls-cli --verify-hostname=mydomain.com --starttls-proto=xmpp jabber.mydomain.com:xmpp-client` --verify-hostname or --sni-hostname does not help. It does work if mydomain.com IN A matches jabber.mydomain.com. However, this should not be a requirement. ## Is this feature implemented in other libraries (and which) `openssl s_client -starttls xmpp -xmpphost mydomain.com -connect jabber.mydomain.com:xmpp-client` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/777 You're receiving 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 May 29 08:39:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:39:29 +0000 Subject: [gnutls-devel] GnuTLS | Name Constraints applied to intermediate CA CN because CA certificate does not have Extended key usage (2.5.29.37) (#776) In-Reply-To: References: Message-ID: Is there a reproducer with gnutls-cli or certtool? pidgin may or may not have additional checks, but you will have to verify that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/776#note_175614056 You're receiving 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 May 29 08:51:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:51:39 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Merge Request !1002 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1002 Branches: tmp-datum-cleanup to master Author: Tim R?hsen Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002 You're receiving 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 May 29 08:52:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:52:40 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: The overall changeset is nice and I trust your investigation, LGTM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175617934 You're receiving 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 May 29 08:53:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:53:10 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Reassigned Merge Request 1002 https://gitlab.com/gnutls/gnutls/merge_requests/1002 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002 You're receiving 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 May 29 08:54:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:54:14 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/srp.c: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175618406 > unsigned int salt_length) > { > _gnutls_free_datum(&cred->fake_salt_seed); > - _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); > + if (_gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size) < 0) { That was addressed in a different way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_175618406 You're receiving 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 May 29 08:54:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 06:54:24 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: All discussions on Merge Request !1002 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/1002 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002 You're receiving 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 May 29 10:34:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 08:34:53 +0000 Subject: [gnutls-devel] GnuTLS | Provide a configuration file (#587) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.9 (May 29, 2019?Jul 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/22 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/587 You're receiving 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 May 29 10:46:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 08:46:54 +0000 Subject: [gnutls-devel] GnuTLS | Enhance the configuration file capabilities (!1013) References: Message-ID: New Merge Request !1013 https://gitlab.com/gnutls/gnutls/merge_requests/1013 Project:Branches: nmav/gnutls:tmp-inih to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: This MR enhances the global configuration file with the ability to override settings for insecure algorithms, allowing local policies in systems using gnutls. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [x] Documentation updated / NEWS entry present (for non-trivial changes) * [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/1013 You're receiving 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 May 29 14:26:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 12:26:11 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1006 was reviewed by Hubert Kario (@mention me if you need reply) -- Hubert Kario (@mention me if you need reply) started a new discussion on tests/suite/tls-fuzzer/tls-fuzzer-nocert.sh: https://gitlab.com/gnutls/gnutls/merge_requests/1006#note_175771028 > if test $? != 0;then > - PRIORITY="NORMAL:%VERIFY_ALLOW_SIGN_WITH_SHA1:+ARCFOUR-128:+3DES-CBC:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:${VERSIONS}:+SHA256" > + PRIORITY="NORMAL:%VERIFY_ALLOW_SIGN_WITH_SHA1:+ARCFOUR-128:+3DES-CBC:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1:${VERSIONS}:+SHA256:%ALLOW_SMALL_RECORDS" shouldn't we test both configurations? with and without it? especially if without it is the default? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006 You're receiving 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 May 29 14:32:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 12:32:34 +0000 Subject: [gnutls-devel] GnuTLS | priority: add new option to allow small records (>= 64) (!1006) In-Reply-To: References: Message-ID: @dueno shouldn't this flag also be added to gnutls-cli-debug? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1006#note_175773878 You're receiving 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 May 29 14:34:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 12:34:21 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1010 was reviewed by Dmitry Eremin-Solenikov -- Dmitry Eremin-Solenikov started a new discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175774785 > + b=`echo $@ | sed 's/.stamp$$//'`; \ > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ This message can be less cryptic, explicitly mentioning that `.bak` is missing, thus calling autogen despite `--enable-local-libopts`. -- Dmitry Eremin-Solenikov started a new discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175774789 > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ > + $(AUTOGEN) $<; \ `$(AM_V_GEN) $(AUTOGEN) $<` ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010 You're receiving 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 May 29 14:35:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 12:35:51 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Looks according to discussions during FOSDEM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_175775586 You're receiving 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 May 29 14:39:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 12:39:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on doc/manpages/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175777248 > autogen -L ../../src -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \ > rm -f "$<".tmp > > +psk2tool.1: $(top_srcdir)/src/psk2.c $(top_srcdir)/src/psk2tool.md.in $(top_srcdir)/src/options.c > + $(top_builddir)/src/psk2tool --options-md >psk2tool.1.txt > + echo "% psk2tool(1) GnuTLS PSK2 tool|GnuTLS $(PACKAGE_VERSION)" > psk2tool.md > + echo >> psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in >> psk2tool.md > + $(PANDOC) -s -f markdown -t man -o psk2tool.1 psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in > psk2tool.md > + $(PANDOC) -s -f markdown -t texinfo -o psk2tool.texi psk2tool.md > + $(MAKEINFO) --force -o psk2tool.info psk2tool.texi > + rm -f psk2tool.1.txt psk2tool.md This rule looks complicated and fragile. E.g. why do you run `sed` twice? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175777248 You're receiving 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 May 29 15:08:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:08:45 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175791577 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We only call AUTOGEN if the .bak files are not present. > +# Normally we wouldn't want to call AUTOGEN here as it is explicitly asked not to, but > +# in certain CI systems, we need to use this > +# our CI systems, which work on > +.def.stamp: > + b=`echo $@ | sed 's/.stamp$$//'`; \ > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ Is the new message better? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175791577 You're receiving 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 May 29 15:10:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:10:26 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175792958 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We only call AUTOGEN if the .bak files are not present. > +# Normally we wouldn't want to call AUTOGEN here as it is explicitly asked not to, but > +# in certain CI systems, we need to use this > +# our CI systems, which work on > +.def.stamp: > + b=`echo $@ | sed 's/.stamp$$//'`; \ > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ Hmm, I don't see it being updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175792958 You're receiving 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 May 29 15:08:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:08:25 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175791509 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We only call AUTOGEN if the .bak files are not present. > +# Normally we wouldn't want to call AUTOGEN here as it is explicitly asked not to, but > +# in certain CI systems, we need to use this > +# our CI systems, which work on > +.def.stamp: > + b=`echo $@ | sed 's/.stamp$$//'`; \ > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ > + $(AUTOGEN) $<; \ Makes sense, done. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175791509 You're receiving 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 May 29 15:20:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:20:40 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175797784 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We do not call AUTOGEN unless the .bak files are missing @lumag do you see it here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175797784 You're receiving 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 May 29 15:21:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:21:35 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175798193 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We only call AUTOGEN if the .bak files are not present. > +# Normally we wouldn't want to call AUTOGEN here as it is explicitly asked not to, but > +# in certain CI systems, we need to use this > +# our CI systems, which work on > +.def.stamp: > + b=`echo $@ | sed 's/.stamp$$//'`; \ > + if ! test -f $${srcdir}$${b}.c.bak;then \ > + echo $${srcdir}$${b}.c.bak; \ I assume you were referring in the comment. I've added a note on the change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175798193 You're receiving 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 May 29 15:21:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:21:41 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175798238 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We do not call AUTOGEN unless the .bak files are missing Ah, I see. I thought about `echo` message. Yes, this one is fine. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175798238 You're receiving 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 May 29 15:41:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:41:29 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: All discussions on Merge Request !1010 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/1010 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010 You're receiving 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 May 29 15:41:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 13:41:46 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175808160 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We do not call AUTOGEN unless the .bak files are missing Is your suggestion to print a message there? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175808160 You're receiving 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 May 29 16:03:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:03:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on doc/manpages/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175818456 > autogen -L ../../src -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \ > rm -f "$<".tmp > > +psk2tool.1: $(top_srcdir)/src/psk2.c $(top_srcdir)/src/psk2tool.md.in $(top_srcdir)/src/options.c > + $(top_builddir)/src/psk2tool --options-md >psk2tool.1.txt > + echo "% psk2tool(1) GnuTLS PSK2 tool|GnuTLS $(PACKAGE_VERSION)" > psk2tool.md > + echo >> psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in >> psk2tool.md > + $(PANDOC) -s -f markdown -t man -o psk2tool.1 psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in > psk2tool.md > + $(PANDOC) -s -f markdown -t texinfo -o psk2tool.texi psk2tool.md > + $(MAKEINFO) --force -o psk2tool.info psk2tool.texi > + rm -f psk2tool.1.txt psk2tool.md Good eyes :-) It's not finalized yet, more like a proof-of-concept. Will re-arrange that to only use sed 1x. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175818456 You're receiving 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 May 29 16:10:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:10:04 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli cannot specify server name while doing xmpp starttls (#777) In-Reply-To: References: Message-ID: It this possibly related to #697 and #766 ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/777#note_175821604 You're receiving 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 May 29 16:13:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:13:07 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175823117 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We do not call AUTOGEN unless the .bak files are missing Yes, I'm sorry for not sounding clear. I suggested to change just file name output to more verbose message. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175823117 You're receiving 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 May 29 16:14:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:14:33 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_175823836 @nmav this will not work, because we need to keep the OID during load/save operations. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_175823836 You're receiving 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 May 29 16:15:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:15:36 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: Merge Request !1002 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1002 Branches: tmp-datum-cleanup to master Author: Tim R?hsen Assignee: Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002 You're receiving 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 May 29 16:54:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 14:54:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: If I understand the approach is to bring libopts functionality into the tools, and use the internal structures to auto-generate part of the documentation based on output provided by the tool itself. Is that correct? That looks sound. I am thinking of the libopts implementation could be a burden in the transition and the future, and there quite some tools which automate that part. Have you considered alternatives (e.g., in libidn2 we use gengetopts)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175842556 You're receiving 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 May 29 17:02:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 15:02:27 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: What is affected by it? I mean is it a problem that the group refers to a single curve of the group? If that relation is used somewhere, would a function in `groups.c` that verifies whether the group/curve are equivalent work? (with that function we could take the mapping info into a separate table). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_175846250 You're receiving 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 May 29 17:03:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 15:03:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: All discussions on Merge Request !1012 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/1012 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012 You're receiving 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 May 29 17:03:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 15:03:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on doc/manpages/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175846635 > autogen -L ../../src -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \ > rm -f "$<".tmp > > +psk2tool.1: $(top_srcdir)/src/psk2.c $(top_srcdir)/src/psk2tool.md.in $(top_srcdir)/src/options.c > + $(top_builddir)/src/psk2tool --options-md >psk2tool.1.txt > + echo "% psk2tool(1) GnuTLS PSK2 tool|GnuTLS $(PACKAGE_VERSION)" > psk2tool.md > + echo >> psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in >> psk2tool.md > + $(PANDOC) -s -f markdown -t man -o psk2tool.1 psk2tool.md > + sed -e '/@OPTIONS@/{r psk2tool.1.txt' -e 'd}' $(top_srcdir)/src/psk2tool.md.in > psk2tool.md > + $(PANDOC) -s -f markdown -t texinfo -o psk2tool.texi psk2tool.md > + $(MAKEINFO) --force -o psk2tool.info psk2tool.texi > + rm -f psk2tool.1.txt psk2tool.md Cleaned up now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175846635 You're receiving 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 May 29 17:05:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 15:05:47 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/Makefile.am: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175847706 > > SUFFIXES = .stamp .def .c.bak .h.bak > > +if NEED_LIBOPTS > +# case --enable-local-libopts: We do not call AUTOGEN unless the .bak files are missing Aha, the echo was there by mistake, but indeed it makes sense. Updated -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_175847706 You're receiving 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 May 29 17:16:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 15:16:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: > If I understand the approach is to bring libopts functionality into the tools, and use the internal structures to auto-generate part of the documentation based on output provided by the tool itself. Is that correct? That's correct. So far I don't see any burden. The psk2 implementation is just a test balloon. `gengetopts` is far less elegant, also needs config files with a certain syntax that nobody can keep in mind. The only 'config file' now is a markdown template (src/psk2tool.md.in). Markdown is so easy to read/write and meanwhile so widespread that it is the format of choice. The option docs come directly from the C file (src/psk2.c), where it belongs - a developer can add / change stuff directly near the implementation without fighting with a just-half-understood config file format (autogen or gengetopts). BTW I couldn't build gengetopts from git on Solaris OpenCSW platform, so it is more of a burden for libidn2 instead of a helper. *If* I put work in libidn2, removing getgetopts is on top of the list. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_175852355 You're receiving 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 May 29 18:50:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 16:50:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli cannot specify server name while doing xmpp starttls (#777) In-Reply-To: References: Message-ID: I don't think so: ``` starttls: sending: starttls: waiting for: " starttls: sending: starttls: waiting for: " ``` Notice to='mydomain.com' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/777#note_175937745 You're receiving 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 May 29 19:46:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 17:46:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli cannot specify server name while doing xmpp starttls (#777) In-Reply-To: References: Message-ID: This line https://gitlab.com/gnutls/gnutls/blob/master/src/socket.c#L250 is always using socket. Maybe we can reuse --verify-hostname arg for that, or create a new "request hostname/xmpp host" (as openssl does): ``` // NOT TESTED const char *host; if (HAVE_OPT(VERIFY_HOSTNAME)) { host = OPT_ARG(VERIFY_HOSTNAME); canonicalize_host((char *) host, NULL, 0); } else host = socket->hostname; snprintf(buf, sizeof(buf), "\n", host); ``` Or redefine socket->hostname inside socket_open2 after conn is openned. Or even a new field in socket for that. I don't know what is the best option. I only know that socket->hostname used by STARTTLS (any protocol) should be user definable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/777#note_175952489 You're receiving 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 May 30 00:15:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 29 May 2019 22:15:27 +0000 Subject: [gnutls-devel] GnuTLS | Name Constraints applied to intermediate CA CN because CA certificate does not have Extended key usage (2.5.29.37) (#776) In-Reply-To: References: Message-ID: I debugged gnutls-cli. It does work as expected. pidgin validates each certificate pair individually (gnutls_x509_crt_verify) while gnutls-cli does the same using a list of certificates (gnutls_certificate_verify_peers). The difference is that while calling gnutls_x509_crt_verify directly, the end_cert parameter in verify_crt is always 1, even while testing an intermediate CA against Root CA. So, intermediate CA is treated as a Server Certificate. So, indeed pidgin bug. Anyway, gnutls should not check name constraints against a CN value that cannot be a DNS name. OpenSSL does check that situation: https://github.com/openssl/openssl/commit/d02d80b2e80adfdde49f76cf7c7af4e013f45005#diff-caf502a9d3e53f3b21e77e5e324b62b4 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/776#note_176032374 You're receiving 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 May 30 07:36:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 05:36:43 +0000 Subject: [gnutls-devel] GnuTLS | Name Constraints applied to intermediate CA CN because CA certificate does not have Extended key usage (2.5.29.37) (#776) In-Reply-To: References: Message-ID: Could you be more specific on which check do you mean here? (the gnutls code) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/776#note_176101276 You're receiving 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 May 30 09:09:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 07:09:17 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: A concern I have is that we use many options used that such tools implement (e.g., flags-cant, disable/enable, argument types, aliases, multiargs(arrays), from checking certtool's and cli's def files). That's a significant amount of features to implement, and to test. Before autogen gnutls I was maintaining most of that stuff in the form of maintaining [gaa](http://gaa.sourceforge.net/); my impression from that was that it was too expensive in time to enhance and maintain such a framework, and it was the main reason for switching to `autogen`. Have you though about building on top of an existing parsing library? If there is one we can rely on, our contribution could be more manageable on the documentation parts. Of course that's based on my experience only. What do you think? PS. ([autogen page](https://www.gnu.org/software/autogen/compare.html) has various alternatives listed, [argtable pops up](https://www.argtable.org/) as it looks like a copylib but haven't checked it more than that). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_176125946 You're receiving 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 May 30 12:24:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 10:24:06 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add src/psk2.c using new src/options.c [skip ci] (!1012) In-Reply-To: References: Message-ID: The wget2 parsing code has (mostly) all of that. I removed the code that isn't needed for psktool. But let me look at certtool next, what is really needed. Maybe we don't need a full implementation of hash tables, vectors etc. Such basics should be in libgnutls anyways... maybe we just need a bit of abstraction around already existing code. > Have you thought about building on top of an existing parsing library? If there is one we can rely on... A parsing library that does exactly what we need is preferable - if it is actively maintained and packaged everywhere (which I doubt it is). I will take a closer look at the alternatives... btw, I am just at splitting libwget into several smaller libraries and will also think about putting the option parsing into an own library as well. So let me drive this further a bit in the next days/weeks so we get some facts to judge on. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1012#note_176185253 You're receiving 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 May 30 14:44:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 12:44:55 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: do not create files when it shouldn't (!1014) References: Message-ID: New Merge Request !1014 https://gitlab.com/gnutls/gnutls/merge_requests/1014 Project:Branches: nmav/gnutls:tmp-fix-touch to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: If a pdf or html file is not distributed, previously `make dist` would create a file called '*.pdf' which did not make sense. This addresses this problem. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [x] Code modified for feature ## 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/1014 You're receiving 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 May 30 15:47:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 13:47:30 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: do not create files when it shouldn't (!1014) In-Reply-To: References: Message-ID: Merge Request !1014 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1014 Project:Branches: nmav/gnutls:tmp-fix-touch to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1014 You're receiving 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 May 30 15:52:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 13:52:42 +0000 Subject: [gnutls-devel] GnuTLS | Makefile.am: do not create files when it shouldn't (!1014) In-Reply-To: References: Message-ID: Merge Request !1014 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1014 Project:Branches: nmav/gnutls:tmp-fix-touch to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1014 You're receiving 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 May 30 21:08:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 30 May 2019 19:08:07 +0000 Subject: [gnutls-devel] GnuTLS | Name Constraints applied to intermediate CA CN because CA certificate does not have Extended key usage (2.5.29.37) (#776) In-Reply-To: References: Message-ID: I'll try to be more specific: 1) First, according to https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/verify.c#L678, verify_crt will not apply name constraints against CA certificates. However, AFAIK, name constraints should only be skipped when it is a self-issued certificate, except when it the final certificate in the path. So it should be checked against intermediate CA, specially against subtrees constraints. > Name constraints are not applied to self-issued certificates (unless > the certificate is the final certificate in the path). (This could > prevent CAs that use name constraints from employing self-issued > certificates to implement key rollover.) > https://tools.ietf.org/html/rfc5280#section-4.2.1.10 2) If CA certificate should be checked against DNS name constraints, it will try to get SubjAltName.DNS at https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1196 . Normally, a CA certificate should not have it. Here https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1223 it is assumed that the certificate being tested is not a CA (but as I mentioned before in 1), it should consider that the cert being tested is a CA). As it assumes that it is not a CA, it only checks key purpose for GNUTLS_KP_TLS_WWW_SERVER. When it did not find Extended key usage (2.5.29.37), it assumes that the certificate can be used as TLS WWW Server. Shouldn't it be better to check CA:true and key usage (2.5.29.15) before? It might avoid testing CN for a certificate that cannot be used for a TLS Service. I don't know exactly what qualifies a certificate to be used in a TLS Service. 3) Finally, it is a certificate suitable for a TLS Service. Considering that there is no SubjectAltName.DNS, it tests CN https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1243. Here, it should test if CN is a valid DNS Name (see openssl commit I cited in my last comment) before testing CN against DNS name constraints. It is uncommon but a server certificate can still be usable without SubjAltName.DNS without relying on CN as it can use SubjAltName.IPAddress or SubjAltName.URI. There is no reason to test CN against DNS name constraints if it is not usable as a DNS Name. BTW, I opened a bug for pidgin problem https://developer.pidgin.im/ticket/17393 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/776#note_176373861 You're receiving 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 May 31 09:41:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 07:41:48 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: @lumag if that's ok with you would you approve? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_176537304 You're receiving 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 May 31 09:43:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 07:43:47 +0000 Subject: [gnutls-devel] GnuTLS | Enhance the configuration file capabilities (!1013) In-Reply-To: References: Message-ID: @lumag I was thinking that this config could be used in the future to replace the default priorities to applications using `gnutls_priority_set_default` and friends, in a way that one can switch the system to enable GOST system-wide if wanted. Currently there is no way to replace the default priority string, but that should be easy to add. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1013#note_176538212 You're receiving 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 May 31 19:53:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 17:53:39 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: @rockdaboot @dueno ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176782225 You're receiving 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 May 31 19:55:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 17:55:04 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Merge Request !1010 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1010 Branches: tmp-fix-libopts to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010 You're receiving 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 May 31 19:55:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 17:55:39 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Merge Request !1010 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1010 Branches: tmp-fix-libopts to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010 You're receiving 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 May 31 19:55:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 17:55:39 +0000 Subject: [gnutls-devel] GnuTLS | autogen is being run on the tarball even if --enable-local-libopts is given (#772) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #772: https://gitlab.com/gnutls/gnutls/issues/772 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/772 You're receiving 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 May 31 19:56:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 17:56:18 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: @nmav done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_176782720 You're receiving 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 May 31 20:27:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 18:27:25 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1011 was reviewed by Tim R?hsen -- Tim R?hsen started a new discussion on RELEASES.md: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176789339 > +|:----:|:-----:|:--------------:| > +|stable|3.6.x |bi-monthly | > +|next |- | | 3.7.0, also bi-monthly ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 31 20:32:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 18:32:39 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Merge Request !1011 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1011 Branches: tmp-releases to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 31 21:08:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 19:08:57 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Merge Request !1011 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1011 Branches: tmp-releases to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 31 22:22:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 20:22:16 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on RELEASES.md: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176812102 > +In the GnuTLS project there are at most two ongoing releases, one marked as > +'stable' and one marked as 'next'. The former is always present and > +supported, while the latter is introduced on the discretion of the > +development team. > + > +For both release branches all the rules in [CONTRIBUTING.md](CONTRIBUTING.md) > +apply, but in principle the 'stable' release is more conservative in new features, > +while the 'next' branch allows for mild behavioral changes. The 'stable' branch > +always provides API and ABI compatibility, while the 'next' branch may on exceptional > +cases change the API. > + > + > +|Branch|Version|Release interval| > +|:----:|:-----:|:--------------:| > +|stable|3.6.x |bi-monthly | > +|next |- | | I haven't thought about the cadence nor when could that release be. At the moment we have the milestone without any dates and potential issues to address: https://gitlab.com/gnutls/gnutls/milestones/20 There is no "process" for starting a next branch, but would it make sense that anyone can propose forking and starting the next branch, and during that proposal we discuss cadence and what gets in from the disruptive changes? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176812102 You're receiving 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 May 31 22:22:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 20:22:23 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: All discussions on Merge Request !1011 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/1011 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 31 22:22:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 20:22:30 +0000 Subject: [gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011) In-Reply-To: References: Message-ID: Merge Request !1011 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/1011 Branches: tmp-releases to master Author: Nikos Mavrogiannopoulos Assignees: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011 You're receiving 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 May 31 22:23:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 20:23:51 +0000 Subject: [gnutls-devel] GnuTLS | Do not regenerate autogen files if --enable-local-libopts is given (!1010) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1010#note_176812583 You're receiving 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 May 31 23:17:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 31 May 2019 21:17:58 +0000 Subject: [gnutls-devel] GnuTLS | Datum.c cleanup (!1002) In-Reply-To: References: Message-ID: The MacOSX build fails with this MR: https://travis-ci.org/gnutls/gnutls/builds/538773566 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1002#note_176822094 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: