From gnutls-devel at lists.gnutls.org Thu Nov 1 11:21:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 10:21:53 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion on lib/priority.c: > + cert_type_priority_all); > } else if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) > - { // Specific server cert type allowed > + (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) { > + // Specific server cert type allowed > fn(&(*priority_cache)->server_ctype, algo); > } else goto error; > } else { // Symmetric certificate type > if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) > - { > + (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) { > fn(&(*priority_cache)->client_ctype, algo); > fn(&(*priority_cache)->server_ctype, algo); > + } else if (strncasecmp(&broken_list[i][1], "CTYPE-OPENPGP", 13) == 0) { Are you sure? Afaict `gnutls_certificate_type_get_id("OPENPGP")` **does** return GNUTLS_CRT_UNKNOWN instead of GNUTLS_CRT_OPENPGP in gnutls 3.6. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_113744806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 11:37:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 10:37:30 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from achraf@achrafsellam.com): TLS problem (#598) In-Reply-To: References: Message-ID: Thank you Nikos Mavrogiannopoulos @nmav! The important in the request I sent you by your email in your website (http://www.gnutls.org) is the gnutls error. I looked up on Google about the number of this error but I did not find no match. I was surprised to see that my email has been public in GITLAB website by you. I know Gnus has a code, I am one of the Gnus. I write this comment as a welcome message from myself for GitLab. I am an engineer wishing to help. I read your answer but I did not understand. But, I think since Filezilla shows that I have GnuTLS Error -50, then I think we should refer to the manual of GnuTLS. I am new with GnuTLS wishing that I can help to improve it. Finally, I think Nikos that you are the developer of GnuTLS. I will follow the request #593 to end. Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/598#note_113749275 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 11:43:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 10:43:44 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: Which relation between #593 and my issue #598 ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593#note_113750501 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 11:50:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 10:50:40 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS does not tolerate record_size_limit extension from server (#599) References: Message-ID: New Issue was created. Issue 599: https://gitlab.com/gnutls/gnutls/issues/599 Author: Nikos Mavrogiannopoulos Assignee: When gnutls client is configured to advertise TLS 1.2 only and is run against NSS server, it aborts with unsupported_extension alert. The server replies with only two extensions: renegotiation_info and record_size_limit -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/599 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 13:10:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 12:10:23 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: They are the same issue. Your applications fails because of this bug. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593#note_113766907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 13:13:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 12:13:18 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > + cert_type_priority_all); > } else if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) > - { // Specific server cert type allowed > + (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) { > + // Specific server cert type allowed > fn(&(*priority_cache)->server_ctype, algo); > } else goto error; > } else { // Symmetric certificate type > if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) > - { > + (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) { > fn(&(*priority_cache)->client_ctype, algo); > fn(&(*priority_cache)->server_ctype, algo); > + } else if (strncasecmp(&broken_list[i][1], "CTYPE-OPENPGP", 13) == 0) { That's my understanding too, and the unit test added actually verifies that this works. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_113767416 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 13:16:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 12:16:05 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS does not tolerate record_size_limit extension from server (#599) In-Reply-To: References: Message-ID: Reassigned Issue 599 https://gitlab.com/gnutls/gnutls/issues/599 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/599 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 13:48:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 12:48:29 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: handle the extension in TLS 1.2 ServerHello (!791) References: Message-ID: New Merge Request !791 https://gitlab.com/gnutls/gnutls/merge_requests/791 Branches: tmp-fix-record-size-limit-tls12 to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Previously it had assumed that TLS 1.2 servers don't send the record_size_limit extension, while actually it can be present in ServerHello. Fixes #599 ## Checklist * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## 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/791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 17:03:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 16:03:05 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/includes/gnutls/gnutls.h.in: > > void gnutls_supplemental_send(gnutls_session_t session, unsigned do_send_supplemental); > > +/* Anti-replay related functions */ > + > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); I have managed to port it to the existing db functions (plus, optional `gnutls_db_check_func` to avoid unnecessary malloc with `gnutls_db_retr_func`). As we discussed off-line, the key shouldn't overlap with TLS 1.2 session ID, as it is always longer than 32 octets. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113866987 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 17:30:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 16:30:25 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/suite/testcompat-tls13-openssl.sh: > kill ${PID} > wait > > + # Try resumption with early data > + echo_cmd "${PREFIX}Checking TLS 1.3 with resumption with early data..." > + testdir=`create_testdir tls13-openssl-resumption` > + eval "${GETPORT}" > + launch_bare_server $$ s_server -quiet -www -accept "${PORT}" -keyform pem -certform pem ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" -CAfile "${CA_CERT}" -early_data > + PID=$! > + wait_server ${PID} > + > + echo "This file contains early data sent by the client" > "${testdir}/earlydata.txt" > + ${VALGRIND} "${CLI}" ${DEBUG} -p "${PORT}" 127.0.0.1 --priority "NORMAL:-VERS-ALL:+VERS-TLS1.3:+GROUP-ALL${ADD}" --earlydata "${testdir}/earlydata.txt" --insecure --inline-commands <<< $(echo -e "^resume^\nGET / HTTP/1.0\r\n\r\n")| tee "${testdir}/client.out" >> ${OUTPUT} I realized that the later version of OpenSSL stopped supporting early data with `-www` option (not sure if there is a plan to add it back, with support for RFC8470). I've removed the HTTP stuff for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113872284 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 17:31:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 16:31:49 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: All discussions on Merge Request !775 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/775 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/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 Thu Nov 1 17:31:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 16:31:52 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/suite/testcompat-tls13-openssl.sh: > kill ${PID} > wait > > + # Try resumption with early data > + echo_cmd "${PREFIX}Checking TLS 1.3 with resumption with early data..." As `s_server` has an option to control the maximum: `-max_early_data`, I have simply added a new test utilizing it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113872568 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 17:52:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 16:52:34 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: All discussions on Merge Request !768 were resolved by Ander Juaristi https://gitlab.com/gnutls/gnutls/merge_requests/768 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/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 Nov 1 20:26:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 19:26:08 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/priority.c: > + cert_type_priority_all); > } else if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) > - { // Specific server cert type allowed > + (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) { > + // Specific server cert type allowed > fn(&(*priority_cache)->server_ctype, algo); > } else goto error; > } else { // Symmetric certificate type > if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) > - { > + (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) { > fn(&(*priority_cache)->client_ctype, algo); > fn(&(*priority_cache)->server_ctype, algo); > + } else if (strncasecmp(&broken_list[i][1], "CTYPE-OPENPGP", 13) == 0) { You guys are right. I was under the assumption that `gnutls_certificate_type_get_id` still returned the correct id for pgp. Forget what I said ;-). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_113905881 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 21:20:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 20:20:35 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) References: Message-ID: New Issue was created. Issue 600: https://gitlab.com/gnutls/gnutls/issues/600 Author: Stefan Berger Assignee: ## Description of problem: The existing tpmtool should be working with an SRK with no password. Basically it needs a command line option to use an SRK with no password. Currently it prompts for a password and pressing return uses an empty password rather than a null password. tpm_takeownership --srk-well-known sets the SRK secret to all zeros (20 bytes of zeros) I know TPM 1.2 is old by now, nevertheless... Maybe we could add the same parameter that tpm_takeownership uses to tpmtool. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 21:32:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 20:32:56 +0000 Subject: [gnutls-devel] GnuTLS | certtool creating authentication failures with TPM 1.2 when TPM SRK uses a password (#601) References: Message-ID: New Issue was created. Issue 601: https://gitlab.com/gnutls/gnutls/issues/601 Author: Stefan Berger Assignee: tpmtool currently requires that a user has a TPM 1.2 SRK password set since it doesn't support the 'well known' SRK password of 20 zero bytes. So if one sets the TPM 1.2 SRK password to a 'string' password, certtool will cause unnecessary authentication failures when trying to talk to the TPM via the tcsd since it will be using the well know SRK password of 20 zero bytes first (certtool seems to support this). The problem with the TPM 1.2 is that it locks down after too many authentication failures and the owner has to send a command to reset it. While we cannot prevent the lock-down entirely (user can always pass a wrong password), we could at least try to minimize the number of failures. So at the moment certtool seems to first try the 'well known' password (which causes an authentication failure) and then prompt the user for the SRK password. Suggestion for forcing certtool to use the SRK password given by user: GNUTLS_SRK_PASSWORD=foo certtool ... # use foo as SRK password on first try For reference, I posted a patch to the TPM 1.2 Trousers mailing list here that describes the issue and fixes a similar issue in tcsd client: https://sourceforge.net/p/trousers/mailman/message/36444514/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/601 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 21:54:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 20:54:23 +0000 Subject: [gnutls-devel] GnuTLS | Please document session ticket key rotation (#581) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #581: https://gitlab.com/gnutls/gnutls/issues/581 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/581 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 21:54:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 20:54:24 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Merge Request !768 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/768 Branches: ajuaristi-update-docs to master Author: Ander Juaristi Assignee: Ander Juaristi -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/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 Nov 1 21:55:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 20:55:44 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Thank you Ander! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_113928809 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 23:25:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 22:25:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_pubkey_t subjectPublicKeyInfo, > + const gnutls_privkey_t key); > + > +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred, Alright. Let's do that. I'll create an issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_113946381 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 1 23:41:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 01 Nov 2018 22:41:04 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) In-Reply-To: References: Message-ID: FYI: [This TPM 2 pkcs11 module](https://github.com/tpm2-software/tpm2-pkcs11) for TPM 2, with some additional patches, can be used for signing. Using 'p11tool --test-sign' works then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594#note_113947997 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 07:32:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 06:32:22 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: handle the extension in TLS 1.2 ServerHello (!791) In-Reply-To: References: Message-ID: Merge Request !791 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/791 Branches: tmp-fix-record-size-limit-tls12 to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 07:32:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 06:32:37 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: handle the extension in TLS 1.2 ServerHello (!791) In-Reply-To: References: Message-ID: LGTM, Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/791#note_113983440 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 07:32:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 06:32:40 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: handle the extension in TLS 1.2 ServerHello (!791) In-Reply-To: References: Message-ID: Merge Request !791 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/791 Branches: tmp-fix-record-size-limit-tls12 to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 07:32:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 06:32:42 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS does not tolerate record_size_limit extension from server (#599) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #599: https://gitlab.com/gnutls/gnutls/issues/599 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/599 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 07:32:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 06:32:55 +0000 Subject: [gnutls-devel] GnuTLS | ext/record_size_limit: handle the extension in TLS 1.2 ServerHello (!791) In-Reply-To: References: Message-ID: Reassigned Merge Request 791 https://gitlab.com/gnutls/gnutls/merge_requests/791 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 10:14:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 09:14:07 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: Well, is's been a month ago a nobody came with suggestions, so this kind of issue doesn't seem to work. Maybe we can use issue boards for tracking of such issues? For 3.6.5 I'd nominate #487, #308 and #597. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_114009233 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 12:46:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 11:46:06 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Merge Request !789 was approved by Tom Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/789 Branches: tmp-ignore-ctypes to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:41:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:41:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: All discussions on Merge Request !789 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/789 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:41:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:41:49 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #593: https://gitlab.com/gnutls/gnutls/issues/593 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:41:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:41:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Merge Request !789 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/789 Branches: tmp-ignore-ctypes to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:41:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:41:48 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #593: https://gitlab.com/gnutls/gnutls/issues/593 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:41:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:41:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Thank you Tom! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_114102798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 14:42:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 13:42:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Reassigned Merge Request 789 https://gitlab.com/gnutls/gnutls/merge_requests/789 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:07:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:07:35 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: Would be nice to try. I do not have much experience with issue boards, would you like to try that for the next release so we see how it is? Currently I'm relying on the board listed by the milestone at: https://gitlab.com/gnutls/gnutls/milestones/17 btw. I've switched the milestone of these issues to 3.6.5. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_114109426 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:17:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:17:06 +0000 Subject: [gnutls-devel] GnuTLS | certtool creating authentication failures with TPM 1.2 when TPM SRK uses a password (#601) In-Reply-To: References: Message-ID: Hmmm, that's indeed ugly. Would you like to submit a merge request with the proposed fix? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/601#note_114111629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:18:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:18:42 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: The problem I have with TPM1.2 is that we don't have any automated test suite, and there is no emulator that we can use in our CI. Nevertheless, if you'd like to suggest fix with a merge request I'd review it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_114112108 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:22:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:22:32 +0000 Subject: [gnutls-devel] GnuTLS | certtool creating authentication failures with TPM 1.2 when TPM SRK uses a password (#601) In-Reply-To: References: Message-ID: What do you think about the proposed solution? Or would the following more general env. variable be more useful for other scenarios as well? ``` GNUTLS_PARENT_KEY_PASSWORD=foo certtool ... # use foo as SRK password on first try ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/601#note_114113046 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:25:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:25:16 +0000 Subject: [gnutls-devel] GnuTLS | LGTM.com integration (#602) References: Message-ID: New Issue was created. Issue 602: https://gitlab.com/gnutls/gnutls/issues/602 Author: Tim R?hsen Assignee: LGTM.com provides static code analyzing, even on a MR basis. Currently it finds 89 'warnings' / 'recommendations', IMO nothing serious. See https://lgtm.com/projects/g/gnutls/gnutls/alerts/?mode=list. To enable it, one of the owners/admins of this project has to sign up at lgtm.com, add the project, activate "enable PR code reviews" and add an `.lgtm.yml` file to the repo. Here is an example of how it looks like in the pipeline of an MR: https://gitlab.com/gnuwget/wget2/pipelines/31139239 As an example, the wget2 `.lgtm.yml` looks like ``` path_classifiers: test: - unit-tests/files extraction: cpp: prepare: packages: - lzip - libgpgme11-dev configure: command: ./bootstrap && ./configure --disable-doc ``` For a first try you could leave away `path_classifiers:` and `prepare:` block. LGTM figures out dependencies pretty well - and they have a short response time when having questions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/602 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 15:40:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 14:40:35 +0000 Subject: [gnutls-devel] GnuTLS | certtool creating authentication failures with TPM 1.2 when TPM SRK uses a password (#601) In-Reply-To: References: Message-ID: The SRK name looked good to me. How do you think a more generic variable could be used (note that certtool/p11tool already rely on `GNUTLS_PIN` environment variable). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/601#note_114117365 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:14:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:14:05 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/system/fastopen.c (#603) References: Message-ID: New Issue was created. Issue 603: https://gitlab.com/gnutls/gnutls/issues/603 Author: Tim R?hsen Assignee: Can we have a simple `return` (do nothing) instead of `abort()` in gnutls_transport_set_fastopen() ? ``` if (connect_addrlen > (socklen_t)sizeof(session->internals.tfo.connect_addr)) { gnutls_assert(); abort(); } ``` Because in production library code I wouldn't expect an abort(). Better having an error returned or a no-op. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/603 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:18:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:18:00 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/extras/hex.c (#604) References: Message-ID: New Issue was created. Issue 604: https://gitlab.com/gnutls/gnutls/issues/604 Author: Tim R?hsen Assignee: hex_encode() may call abort() via hexchar(). I think this is not appropriate for library code. That function is used by gnutls_hex_encode() and gnutls_hex_encode2() which are used by other library functions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:20:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:20:57 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/extras/hex.c (#604) In-Reply-To: References: Message-ID: Also abort() is used in lib/x509/privkey_pkcs8_pbes1.c and lib/nettle/mac.c. An assertion would be good plus an appropriate error handling in production code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/604#note_114126884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:47 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c: > + gnutls_db_retr_func db_retrieve_func; > + gnutls_db_store_func db_store_func; > + void *db_ptr; > + int ret = 0; > + > + if (unlikely(id->size > MAX_HASH_SIZE)) > + return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > + > + gnutls_gettime(&now); > + server_ticket_age = timespec_sub_ms(&now, ticket_creation_time); > + > + /* It shouldn't be possible that the server's view of ticket > + * age is smaller than the client's view. > + */ > + if (unlikely(server_ticket_age < client_ticket_age)) > + return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); If the client ticket age is taken by the client message; maybe some illegal parameter error is better here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129495 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:47 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > + at funcref{gnutls_anti_replay_set_window}. > + > +The anti-replay mechanism shall be globally initialized with > + at funcref{gnutls_anti_replay_init}, and then attached to a session using > + at funcref{gnutls_anti_replay_enable}. It can be deinitialized with > + at funcref{gnutls_anti_replay_deinit}. > + > +By default, the mechanism stores the ClientHello messages on the process > +memory. For a long-running server or distributed servers, you can set > +back-end functions with @funcref{gnutls_db_set_check_function} and > + at funcref{gnutls_db_set_store_function} (see @ref{Session resumption}). > + > +Although those back-end functions can be the same as the one used for > +TLS 1.2 session resumption, there are a couple of things to note. > +Firstly, as the anti-replay mechanism doesn't use values associate with > +the keys, the store function takes the same data as key and value. I needed to read the sentence multiple times. Maybe using "database keys" would make it more clear. However, what is said here is also an internal detail. We may not want to really commit on what we write on that db. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129494 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:47 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c: > + gnutls_free(anti_replay); > +} > + > +/** > + * gnutls_anti_replay_enable: > + * @session: is a #gnutls_session_t type. > + * @anti_replay: is a #gnutls_anti_replay_t type. > + * > + * Request that the server should use anti-replay mechanism. > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, or an > + * error code. > + * > + * Since: 3.6.5 > + **/ > +int should we make it return void for simplicity? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129490 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:48 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c: > + _gnutls_write_uint32(anti_replay->start_time.tv_nsec, p); > + p += 4; > + memcpy(p, id->data, id->size); > + p += id->size; > + key.data = buffer; > + key.size = p - buffer; > + > + if ((session->internals.db_check_func || > + session->internals.db_retrieve_func) && > + session->internals.db_store_func) { > + db_check_func = session->internals.db_check_func; > + db_retrieve_func = session->internals.db_retrieve_func; > + db_store_func = session->internals.db_store_func; > + db_ptr = session->internals.db_ptr; > + } else { > + db_check_func = storage_check; What do you think on avoiding having a memory back-end for simplicity? I worry that this is something that apps will want to tweak anyway, for memory usage/performance of it and it may become over-engineered later to cover all possible scenarios. gnutls-serv has already such a memory back-end, and I'd expect any other servers which support resumption already do as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129497 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:49 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > + at funcref{gnutls_anti_replay_init}, and then attached to a session using > + at funcref{gnutls_anti_replay_enable}. It can be deinitialized with > + at funcref{gnutls_anti_replay_deinit}. > + > +By default, the mechanism stores the ClientHello messages on the process > +memory. For a long-running server or distributed servers, you can set > +back-end functions with @funcref{gnutls_db_set_check_function} and > + at funcref{gnutls_db_set_store_function} (see @ref{Session resumption}). > + > +Although those back-end functions can be the same as the one used for > +TLS 1.2 session resumption, there are a couple of things to note. > +Firstly, as the anti-replay mechanism doesn't use values associate with > +the keys, the store function takes the same data as key and value. > +Secondly, the back-end needs to periodically clean up the stored entries > +based on the time window set with > + at funcref{gnutls_anti_replay_set_window}. What about adding: "the cleanup can be implemented by iterating through the database entries and calling `gnutls_db_check_entry_time`. This is similar to session database cleanup used by TLS1.2 sessions."? Is that the suggested process? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129498 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:51 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c: > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } else { > + gnutls_datum_t value; > + > + value = db_retrieve_func(db_ptr, key); > + if (value.data) { > + /* We don't care about the data. */ > + free(value.data); > + _gnutls_handshake_log("anti_replay: duplicate ClientHello found\n"); > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } > + between this read and store there is a window that an session on another server in a pool would accept the same hello message. Seeing how `apr_memcache` works it has an `apr_memcache_add` command which can add only when it doesn't exist, and otherwise return an error. Maybe we can rely on that, instead on separate read and store? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129499 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:48 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > + ... > + > + /* Retrieve early data in a handshake hook; > + * you can also do that after handshake. > + */ > + gnutls_handshake_set_hook_function(server, GNUTLS_HANDSHAKE_END_OF_EARLY_DATA, > + GNUTLS_HOOK_POST, handshake_hook_func); > + ... > +@} > + at end example > + > + > + at node Anti-replay protection > + at subsection Anti-replay protection > + > +When 0-RTT mode is used, it is suggested that the server protect itself `When 0-RTT mode is used, it is suggested that the server protect itself` maybe to: `When 0-RTT mode is used, the server must protect itself` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129489 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 16:31:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 15:31:49 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > +to a certain time window, which can be configured with > + at funcref{gnutls_anti_replay_set_window}. > + > +The anti-replay mechanism shall be globally initialized with > + at funcref{gnutls_anti_replay_init}, and then attached to a session using > + at funcref{gnutls_anti_replay_enable}. It can be deinitialized with > + at funcref{gnutls_anti_replay_deinit}. > + > +By default, the mechanism stores the ClientHello messages on the process > +memory. For a long-running server or distributed servers, you can set > +back-end functions with @funcref{gnutls_db_set_check_function} and > + at funcref{gnutls_db_set_store_function} (see @ref{Session resumption}). > + > +Although those back-end functions can be the same as the one used for > +TLS 1.2 session resumption, there are a couple of things to note. > +Firstly, as the anti-replay mechanism doesn't use values associate with s/associate/associated/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114129492 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 17:40:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 16:40:22 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tls13/anti_replay.c: > + _gnutls_write_uint32(anti_replay->start_time.tv_nsec, p); > + p += 4; > + memcpy(p, id->data, id->size); > + p += id->size; > + key.data = buffer; > + key.size = p - buffer; > + > + if ((session->internals.db_check_func || > + session->internals.db_retrieve_func) && > + session->internals.db_store_func) { > + db_check_func = session->internals.db_check_func; > + db_retrieve_func = session->internals.db_retrieve_func; > + db_store_func = session->internals.db_store_func; > + db_ptr = session->internals.db_ptr; > + } else { > + db_check_func = storage_check; I agree. I'll move it to gnutls-serv. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114143757 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 17:41:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 16:41:04 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tls13/anti_replay.c: > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } else { > + gnutls_datum_t value; > + > + value = db_retrieve_func(db_ptr, key); > + if (value.data) { > + /* We don't care about the data. */ > + free(value.data); > + _gnutls_handshake_log("anti_replay: duplicate ClientHello found\n"); > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } > + Yes, it makes sense. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114143895 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 19:16:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 18:16:24 +0000 Subject: [gnutls-devel] GnuTLS | LGTM.com integration (#602) In-Reply-To: References: Message-ID: I'd say let's try it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/602#note_114162316 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 19:19:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 18:19:44 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/system/fastopen.c (#603) In-Reply-To: References: Message-ID: returning would mean that this "impossible" situation will never be caught and the application developer will never detect the error. What about using `assert()`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/603#note_114163143 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 19:26:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 18:26:26 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/extras/hex.c (#604) In-Reply-To: References: Message-ID: The `abort()` in `hexchar()` is an impossible situation so it is unreachable code. We can certainly remove it. In nettle lib and `pbkdf1_md5()` using assert is more appropriate (again impossible situations, but good to have I think as they may reveal bugs in future rewrites). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/604#note_114163934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 20:22:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 19:22:25 +0000 Subject: [gnutls-devel] GnuTLS | Avoid abort() in lib/system/fastopen.c (#603) In-Reply-To: References: Message-ID: Ah, I thought gnutls_assert() is a wrapper around assert() ... it looks like it just prints a message. Then gnutls_assert() followed by return should be ok in this case. Not using TFO doesn't hurt that much in this unlikely case - and there still will be a message. assert() followed by return would be ok as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/603#note_114174503 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 20:33:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 19:33:25 +0000 Subject: [gnutls-devel] GnuTLS | gl/memxor.[ch] needed ? (#605) References: Message-ID: New Issue was created. Issue 605: https://gitlab.com/gnutls/gnutls/issues/605 Author: Tim R?hsen Assignee: We do not use the gnulib module 'memxor', but I see in `gnutls_int.h`: ``` #ifdef HAVE_LIBNETTLE #include #else #include #define memxor gl_memxor #endif ``` Either this code is obsolete or we should include memxor in bootstrap.conf. BTW, in `lib/nettle/rnd-fips.c` we include nettle/memxor.h unconditionally. Is it even possible to build gnutls without nettle ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 2 21:30:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 02 Nov 2018 20:30:44 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: I may have something to help automate a test suite if we can use git clone (twice) during the test and can use openssl's crypto library. Basically it's libtpms + swptm projects that can be used for TPM emulation of TPM 1.2 and TPM 2.0 along with the tcsd using swtpm as a replacement for a hardware TPM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_114205977 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 03:26:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 02:26:20 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) References: Message-ID: New Merge Request !792 https://gitlab.com/gnutls/gnutls/merge_requests/792 Project:Branches: stefanberger/gnutls:tpm12_fixes to gnutls/gnutls:master Author: Stefan Berger Assignee: This pull request fixes issues #600 and #601. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:40:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:40:54 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: We have already some submodules used for testing (openssl being one for tls1.3 interop testing), though the best option would be if we can bring these to fedora or debian to eliminate the build step. Are these already in one of these distributions? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_114249628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:42:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:42:02 +0000 Subject: [gnutls-devel] GnuTLS | gl/memxor.[ch] needed ? (#605) In-Reply-To: References: Message-ID: Indeed, that looks like a leftover from the time where nettle was only an option. nettle is a mandatory option as it is now and cannot be replaced without a significant effort. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/605#note_114249685 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:45:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:45:23 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: The failures seem to be due to timeouts in the CI, You will need to increase the default timeout to 2h or at least 90min, at settings -> CI -> general pipelines, of your forked project. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114249763 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:49:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:49:04 +0000 Subject: [gnutls-devel] GnuTLS | Replace AUTHORS with CODEOWNERS (#606) References: Message-ID: New Issue was created. Issue 606: https://gitlab.com/gnutls/gnutls/issues/606 Author: Nikos Mavrogiannopoulos Assignee: The AUTHORS file has been unmaintained for some time, and recent contributors are not properly acknowledged. Taking opportunity from the [`CODEOWNERS`](https://gitlab.com/help/user/project/code_owners) feature of gitlab, we should migrate to it, replacing `AUTHORS`, and update it to contain a more accurate information. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/606 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:54:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:54:50 +0000 Subject: [gnutls-devel] GnuTLS | Replace AUTHORS with CODEOWNERS (#606) In-Reply-To: References: Message-ID: That may not be that straightforward as we haven't agreed on any code ownership process. Maybe that's something to be discussed during the fosdem f2f. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/606#note_114250636 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 07:55:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 06:55:41 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) In-Reply-To: References: Message-ID: This depends on bringing softhsm 2.5.0 to the CI. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790#note_114250648 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 12:55:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 11:55:25 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: I've sketched an [issue board](https://gitlab.com/gnutls/gnutls/boards/846394), listing issues targeting 3.6.5 and bugfixes for 3.6.x. Using it you can drag and drop issues to target this release or to remove issues from the release as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_114264791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 12:59:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 11:59:31 +0000 Subject: [gnutls-devel] GnuTLS | gl/memxor.[ch] needed ? (#605) In-Reply-To: References: Message-ID: Few years ago I had mostly working support for libgcrypt backend. However with GnuTLS using Nettle's PBKDF2 API directly it became obsolete. It might be a nice student project to support building GnuTLS without Nettle (using only lib/accelerated or even just in-kernel crypto). Or with libgcrypt/M$ CryptoAPI backends. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/605#note_114264953 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 14:55:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 13:55:05 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: They are heading into Fedora 29 next, can already be found in Rawhide. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_114284297 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:32:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:32:59 +0000 Subject: [gnutls-devel] GnuTLS | an application cannot opt-out from cipher settings update (#176) In-Reply-To: References: Message-ID: Closing in favor of #587 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/176#note_114313367 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:33:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:33:00 +0000 Subject: [gnutls-devel] GnuTLS | an application cannot opt-out from cipher settings update (#176) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #176: https://gitlab.com/gnutls/gnutls/issues/176 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/176 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:35:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:35:08 +0000 Subject: [gnutls-devel] GnuTLS | 3.5.x: Prevent SHA1 from being used for certificate verification by default (#174) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #174: https://gitlab.com/gnutls/gnutls/issues/174 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/174 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:35:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:35:08 +0000 Subject: [gnutls-devel] GnuTLS | 3.5.x: Prevent SHA1 from being used for certificate verification by default (#174) In-Reply-To: References: Message-ID: This never happened on 3.5.x and since it is going to be replaced by 3.6.x branch as stable soon, I do not think it makes sense to follow up with that plan. Closing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/174#note_114313495 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:36:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:36:26 +0000 Subject: [gnutls-devel] GnuTLS | certtool test fails on 3.6.3, not 3.6.2 (regression) (#560) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #560: https://gitlab.com/gnutls/gnutls/issues/560 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/560 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 18:36:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 17:36:41 +0000 Subject: [gnutls-devel] GnuTLS | certtool test fails on 3.6.3, not 3.6.2 (regression) (#560) In-Reply-To: References: Message-ID: Closing due to insufficient information. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/560#note_114313593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 3 22:03:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 03 Nov 2018 21:03:20 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114322964 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 4 12:34:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 04 Nov 2018 11:34:15 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) References: Message-ID: New Merge Request !793 https://gitlab.com/gnutls/gnutls/merge_requests/793 Project:Branches: GostCrypt/gnutls:args-std-def to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [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/793 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 4 13:33:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 04 Nov 2018 12:33:51 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: This change would introduce a hard build-time dependency on autogen, even when building from a release tarball, wouldn't it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_114356122 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 4 14:09:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 04 Nov 2018 13:09:52 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Isn't this basically the same as !754 ? See comments over there... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_114360091 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 4 22:46:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 04 Nov 2018 21:46:17 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav Could you explain to me how I can run the MIPS tests locally? I've downloaded the docker image for the debian cross build and ran the tests. But locally all tests succeed. How can I get the same (mips) setup as the CI? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_114392068 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 09:25:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 08:25:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: The docker image is rebuilt regularly. So you likely downloaded a newer image... Could you just restart the failed runner ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_114468411 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 10:30:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 09:30:05 +0000 Subject: [gnutls-devel] GnuTLS | WIP: src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Marked as WIP for now. Indeed it's mostly the same as !754. Strange that I've missed it. I have a quick and dirty fix for Autogen requirement -- to add `args-std.def` file temporarily to regenrate args files. However I'd like to reshuffle those bits a bit: merge `dist-hook` with part of `files-update` to let Make take care about dependencies/updating files. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_114485329 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 19:57:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 18:57:15 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tpm.c: > { > CHECK_INIT; > > + if (!srk_password) Hmm, can this call to environment variable moved to the tool instead? The library doesn't use these env variables; only the tools do. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114675061 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 20:03:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 19:03:43 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Given that we have no CI at the moment with TPM I'd add as a checklist whether basic functionality of the newly added option is done manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114676686 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 20:09:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 19:09:26 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: That's great! Do you have some idea of how we can use these tools to provide a basic functionality testing similarly to `tests/testpkcs11.sh`, or even suggest such testing? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_114677491 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 20:12:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 19:12:41 +0000 Subject: [gnutls-devel] GnuTLS | update CI to fedora29 (#607) References: Message-ID: New Issue was created. Issue 607: https://gitlab.com/gnutls/gnutls/issues/607 Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos This will enable to use newer versions of several components we rely on: - tpm tools - softhsm (with ed25519) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 20:26:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 19:26:25 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on lib/tpm.c: > { > CHECK_INIT; > > + if (!srk_password) That's difficult... certtool takes the route via `gnutls_privkey_import_url`, which then calls `gnutls_privkey_import_tpm_url` with the SRK password as NULL since `gnutls_privkey_import_url` doesn't take the SRK password as a possible parameter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114680312 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 21:40:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 20:40:30 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tpm.c: > { > CHECK_INIT; > > + if (!srk_password) In the corresponding case for PKCS#11, we can pass the password/pin via the URI itself (e.g., by the ?pin-value option). In the tpmkey URI we didn't have such a provision. @dwmw2 is considering revising the spec for TPM2.0 though; would it make sense to have such a provision added? That wouldn't address the issue soon enough though. Any better ideas welcome. In the meantime would it make sense to split the fixes to #600 and #601 into different MRs? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114691010 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 21:45:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 20:45:21 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .gitlab-ci.yml: move to fedora29 for CI (!794) References: Message-ID: New Merge Request !794 https://gitlab.com/gnutls/gnutls/merge_requests/794 Branches: tmp-f29 to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This moves the CI to use the newly released Fedora 29. ## Checklist * [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/794 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 21:53:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 20:53:55 +0000 Subject: [gnutls-devel] GnuTLS | Rename key set functions (API) to reflect the fact that they set a key pair (#608) References: Message-ID: New Issue was created. Issue 608: https://gitlab.com/gnutls/gnutls/issues/608 Author: Tom Assignee: In the current code there are some API functions for settings key pairs. These functions are named such that it is not clear that they actually set a key pair. E.g.: `gnutls_certificate_set_x509_key_mem()` At the next ABI break we might want to rename these functions. E.g. to: `gnutls_certificate_set_x509_keypair_mem()` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 21:58:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 20:58:22 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on lib/tpm.c: > { > CHECK_INIT; > > + if (!srk_password) @nmav I will split them up now. I think the --srk-well-known is safer to merge. I have an alternative to the above but it's playing around with the PIN callback behavior... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792#note_114693596 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 21:58:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 20:58:45 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: All discussions on Merge Request !650 were resolved by Tom https://gitlab.com/gnutls/gnutls/merge_requests/650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 22:03:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 21:03:31 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) References: Message-ID: New Merge Request !795 https://gitlab.com/gnutls/gnutls/merge_requests/795 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_600 to gnutls/gnutls:master Author: Stefan Berger Assignee: This merge request fixes issue #600 by implementing --srk-well-known so that the tpmtool works when the SRK has been set to the 'well known' password of 20 zero bytes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 22:12:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 21:12:53 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) References: Message-ID: New Merge Request !796 https://gitlab.com/gnutls/gnutls/merge_requests/796 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_601 to gnutls/gnutls:master Author: Stefan Berger Assignee: This merge request fixes issue #601 by first calling the PIN callback and retrieving the value from the GNUTLS_PIN environment variable, if available, and then falling back to using srk_password = NULL if the value from the PIN callback did not work. If the PIN callback does not provide a valid value, we just use srk_password = NULL, which is again the 20 zero bytes (well known) password. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 5 22:13:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 05 Nov 2018 21:13:19 +0000 Subject: [gnutls-devel] GnuTLS | TPM fixes (!792) In-Reply-To: References: Message-ID: Merge Request !792 was closed by Stefan Berger Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/792 Project:Branches: stefanberger/gnutls:tpm12_fixes to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/792 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 09:22:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 08:22:07 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: i386/i686 libc6-dev isn't installed !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794#note_114770080 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 09:40:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 08:40:33 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) References: Message-ID: New Merge Request !797 https://gitlab.com/gnutls/gnutls/merge_requests/797 Branches: tmp-remove-gl-memxor to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes #605 ## Checklist * [ ] 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/797 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:05:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:05:40 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: I can't see any relations between the PR and the failing `testcompat-openssl` test. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114866403 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:08:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:08:45 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: Neither do I. Here is failed test log: ``` Compatibility checks using OpenSSL 1.1.1 11 Sep 2018 Disabling interop tests for RC4 ciphersuites Disabling interop tests for 3DES ciphersuites Disabling interop tests for NULL ciphersuites Disabling interop tests for SSL 3.0 ################################################# # Client mode tests (gnutls cli-openssl server) # ################################################# try 1 try 1 try 1 try 2 try 2 try 2 try 3 try 3 try 3 try 4 try 4 try 4 try 5 try 5 try 5 try 6 try 6 try 6 Server 22511 did not come up ./testcompat-main-openssl: 186: kill: No such process Server 42933 did not come up ./testcompat-main-openssl: 186: kill: No such process Server 9139 did not come up ./testcompat-main-openssl: 186: kill: No such process FAIL testcompat-openssl.sh (exit status: 1) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114870009 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:32:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:32:04 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: The debian image was regenerated :( I suspect it removed SSL3.0 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114876476 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:33:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:33:30 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: or it seems it updated to 1.1.1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114876878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:36:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:36:42 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) In-Reply-To: References: Message-ID: Merge Request !795 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/795 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_600 to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 13:38:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 12:38:08 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) In-Reply-To: References: Message-ID: Thank you. The failure in the CI is something unrelated (debian image was updated which brought openssl 1.1.1 and that makes the interop tests to fail) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795#note_114878459 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 15:11:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 14:11:16 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: On Debian unstable openssl 1.1.1 is current. But you could also install `libssl1.0-dev` which currently is openssl 1.0.2o-1. No sure how both packages/versions work together. But better to detect the version or missing feature in the test itself. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114912183 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 15:31:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 14:31:51 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: `libssl1.0-dev`/`libssl1.0` allow co-installation of the library. The `openssl` package however comes from version 1.1.1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_114918126 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 18:26:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 17:26:36 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: @ametzler @rockdaboot @nmav I've finished this, could you please review? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_114972430 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 18:48:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 17:48:22 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tls13/anti_replay.c: > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } else { > + gnutls_datum_t value; > + > + value = db_retrieve_func(db_ptr, key); > + if (value.data) { > + /* We don't care about the data. */ > + free(value.data); > + _gnutls_handshake_log("anti_replay: duplicate ClientHello found\n"); > + ret = gnutls_assert_val(GNUTLS_E_EARLY_DATA_REJECTED); > + goto out; > + } > + } > + OK, I added `gnutls_db_add_func` and replaced the use of `gnutls_db_check_func` and `gnutls_db_store_func` in anti_replay.c with it. Also removed the bloom filter stuff that would require periodical batch cleanup. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_114983869 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 18:48:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 17:48:30 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: All discussions on Merge Request !775 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/775 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/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 Tue Nov 6 22:04:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 21:04:15 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav could you give this one another review? I've addressed all the issues that you've commented on. Moreover I've added trustdb support for raw public keys. I also extended the test cases. Currently this MR contains all separate commits. If you approve this MR then I will squash them into 1 commit but for the sake of comparability (and easy development) I've pushed my dev branch to this MR. Please forgive me if there are some (useless) whitespace changes in this MR. I sometimes forgot to turn off line ending trimming in my editor. At this moment only 1 test is failing (testcompat-openssl.sh) in the abi/coverage.debian image. Could you please take a look at the test log and give me a hint what could be wrong? I'm not a hero in shell scripting and I can't make much sense of the logs because I don't know what the correct output should look like. Thanks in advance. Finally, it would be cool if we can have this one accepted before the release of 3.6.5. Do you think we can make that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_115021865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 6 22:56:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 06 Nov 2018 21:56:56 +0000 Subject: [gnutls-devel] GnuTLS | WIP: GOST cryptography support (!133) In-Reply-To: References: Message-ID: This is delayed till we publish TLS spec for GOST cipher suites. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/133#note_115029036 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 09:45:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 08:45:51 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: The error output is: ``` error setting certificate 139785824786240:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_115101999 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 10:22:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 09:22:52 +0000 Subject: [gnutls-devel] GnuTLS | WIP: This fixes the recent issue with openssl interop testing in CI (!798) References: Message-ID: New Merge Request !798 https://gitlab.com/gnutls/gnutls/merge_requests/798 Branches: tmp-fix-ci-runs to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes the openssl interop issue in CI. ## Checklist * [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/798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 10:26:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 09:26:28 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) References: Message-ID: New Issue was created. Issue 609: https://gitlab.com/gnutls/gnutls/issues/609 Author: Nikos Mavrogiannopoulos Assignee: `gnutls_x509_crt_get_expiration_time` can accept -1 to set the no well defined expiration time, however if the documented macro is used (`GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION`), this does not result to the no well defined expiration time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 10:27:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 09:27:03 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Something like the following should be sufficient, in addition to a testsuite check. ``` diff --git a/lib/x509/time.c b/lib/x509/time.c index 4d2b78926..b3d799400 100644 --- a/lib/x509/time.c +++ b/lib/x509/time.c @@ -238,7 +238,7 @@ gtime_to_suitable_time(time_t gtime, char *str_time, size_t str_time_size, unsig size_t ret; struct tm _tm; - if (gtime == (time_t)-1 + if (gtime == GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION || gtime == (time_t)-1 #if SIZEOF_LONG == 8 || gtime >= 253402210800 #endif @@ -277,7 +277,7 @@ gtime_to_generalTime(time_t gtime, char *str_time, size_t str_time_size) size_t ret; struct tm _tm; - if (gtime == (time_t)-1 + if (gtime == GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION || gtime == (time_t)-1 #if SIZEOF_LONG == 8 || gtime >= 253402210800 #endif @@ -409,6 +409,7 @@ _gnutls_x509_set_time(ASN1_TYPE c2, const char *where, time_t tim, ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609#note_115116078 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 10:59:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 09:59:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on tests/suite/testcompat-main-openssl: > > test $NO_TLS1_2 != 0 && echo "Disabling interop tests for TLS 1.2" > > +${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1 > +NO_DSS=$? This is unnecessary, you will overwrite `NO_DSS` in version check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115125975 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 14:44:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 13:44:36 +0000 Subject: [gnutls-devel] GnuTLS | WIP: This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Most likely we need to keep a CI test with openssl 1.1.0 around to ensure that we test the legacy stuff as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115191413 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 15:51:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 14:51:53 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/suite/testcompat-main-openssl: > > test $NO_TLS1_2 != 0 && echo "Disabling interop tests for TLS 1.2" > > +${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1 > +NO_DSS=$? Thanks, fixed in the update. It seems that secp192r1 was prohibited as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115221697 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 15:51:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 14:51:57 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: All discussions on Merge Request !798 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/798 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 16:47:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 15:47:11 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Merge Request !775 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/775 Branches: tmp-0rtt 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/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 Wed Nov 7 16:50:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 15:50:55 +0000 Subject: [gnutls-devel] GnuTLS | test 0rtt replays on gnutls-serv (#610) References: Message-ID: New Issue was created. Issue 610: https://gitlab.com/gnutls/gnutls/issues/610 Author: Nikos Mavrogiannopoulos Assignee: Currently we unit test 0rtt but we do not check whether a replay is caught by gnutls-serv. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 17:45:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 16:45:36 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: @nmav Debian stable has OpenSSL 1.1.0, but it also has Nettle 3.3. I can backport Nettle 3.4, if you wish. Other options might be to use Fedora 28 or Ubuntu 18.04 LTS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115263963 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 7 22:17:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 07 Nov 2018 21:17:52 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) In-Reply-To: References: Message-ID: Is there anything I should do here for the failure, or you'll merge it at some point? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795#note_115370115 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 8 07:17:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 08 Nov 2018 06:17:12 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: On the other hand the advantage is that we do not need to re-compile openssl to have tls1.3 support. If we keep `SSL-3.0.Fedora.x86_64` run with fedora28 I think we are ok. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115427638 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 8 11:04:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 08 Nov 2018 10:04:42 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Should we get it in? I'll try to make sure we have the previous test coverage as part of !794 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798#note_115477771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 8 12:05:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 08 Nov 2018 11:05:36 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) In-Reply-To: References: Message-ID: No need to act. I'll merge it once !798 is in place. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795#note_115502200 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 8 11:05:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 08 Nov 2018 10:05:49 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: I gave up on fedora x86 and used debian instead. Some things fail though there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794#note_115478065 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 8 17:00:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 08 Nov 2018 16:00:18 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: I have fixed an issue: the database entries stored by anti-replay were not in the format that `gnutls_db_check_entry_time()` expects. However, I now have a question about that. If we store both TLS 1.2 session data and TLS 1.3 anti-replay entries in the same database, how the expiration time should be calculated? While TLS 1.2 session data can be valid for 7 days, TLS 1.3 anti-replay entries should remain much shorter. Maybe an idea would be to encode the expiration time in database entry, and make `gnutls_db_check_entry` to check that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_115704982 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 01:27:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 00:27:32 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Merge Request !798 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/798 Branches: tmp-fix-ci-runs to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 01:27:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 00:27:36 +0000 Subject: [gnutls-devel] GnuTLS | This fixes the recent issue with openssl interop testing in CI (!798) In-Reply-To: References: Message-ID: Merge Request !798 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/798 Branches: tmp-fix-ci-runs to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 06:35:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 05:35:27 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) 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/795#note_115864247 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 06:35:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 05:35:33 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool: Support --srk-well-known for SRK with 20 zero bytes password (!795) In-Reply-To: References: Message-ID: Merge Request !795 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/795 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_600 to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/795 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 06:35:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 05:35:56 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #600: https://gitlab.com/gnutls/gnutls/issues/600 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 06:35:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 05:35:55 +0000 Subject: [gnutls-devel] GnuTLS | tpmtool not accepting SRK with no password (#600) In-Reply-To: References: Message-ID: Addressed with 4151d1173f1937f64813222faca710410fe4ec14 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/600#note_115864289 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 16:05:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 15:05:44 +0000 Subject: [gnutls-devel] GnuTLS | certtool --p7-info should parse PKCS#7 attributes (#611) References: Message-ID: New Issue was created. Issue 611: https://gitlab.com/gnutls/gnutls/issues/611 Author: Dmitry Eremin-Solenikov Assignee: ## Description of the feature: `certool --p7-info` should print details about known PKCS7 attributes (name and parsed contents), like it does for x.509 extensions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/611 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 16:11:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 15:11:50 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) References: Message-ID: New Issue was created. Issue 612: https://gitlab.com/gnutls/gnutls/issues/612 Author: Dmitry Eremin-Solenikov Assignee: Dmitry Eremin-Solenikov ## Description of problem: GnuTLS fails on two examples from [RFC 4134](https://tools.ietf.org/html/rfc4134): - It fails to parse example from Section 4.5 (`import error: ASN1 parser: Error in DER parsing.`) - It fails to verify second signature on example from Section 4.6 ## Version of gnutls used: GnuTLS master branch (gnutls_3_6_4-109-g4151d1173f19) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 21:10:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 20:10:22 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: A rebase is needed and should pass. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797#note_116119662 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 21:10:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 20:10:37 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: Merge Request !797 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/797 Branches: tmp-remove-gl-memxor to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 9 21:10:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 09 Nov 2018 20:10:51 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: Reassigned Merge Request 797 https://gitlab.com/gnutls/gnutls/merge_requests/797 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/797 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 09:37:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 08:37:14 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_PIN_FINAL_TRY: This is the final try before blocking. > * @GNUTLS_PIN_COUNT_LOW: Few tries remain before token blocks. > * @GNUTLS_PIN_WRONG: Last given PIN was not correct. > + * @GNUTLS_PIN_MAY_BE_MISSING: It is fine if the PIN is missing. Could you elaborate a little on that flag? For example, what should be the behavior of the callback if that flag is seen? Which type of PINs it currently applies to. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116185070 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 09:39:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 08:39:07 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tpm.c: > char pin1[GNUTLS_PKCS11_MAX_PIN_LEN]; > char pin2[GNUTLS_PKCS11_MAX_PIN_LEN]; > int ret, ret2; > + int srk_password_was_null = srk_password == NULL; > + > + if (!srk_password) { maybe using the introduced variable would be more natural; though looks good as it is. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116185354 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 09:46:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 08:46:10 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tpm.c: > > if (attempts > 0) > flags |= GNUTLS_PIN_WRONG; > + else This applies to all callers of `tpm_pin()`, is that intentional, or it should have applied to the specific caller modified later? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116186524 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 09:49:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 08:49:11 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: The CI should successfully run after a rebase in master, however I think that's a behavioral change, and I'm afraid of it without us having anything to test with. Should we add some use-case tests of tpmtool and certtool affected by this change, using the component you previously mentioned? Hopefully with !794 we will move the CI to fedora29 quite soon. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116186878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 17:09:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 16:09:30 +0000 Subject: [gnutls-devel] GnuTLS | Unconditionally include nettle/memxor.h (!797) In-Reply-To: References: Message-ID: Merge Request !797 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/797 Branches: tmp-remove-gl-memxor 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/797 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 17:09:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 16:09:30 +0000 Subject: [gnutls-devel] GnuTLS | gl/memxor.[ch] needed ? (#605) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #605: https://gitlab.com/gnutls/gnutls/issues/605 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 18:10:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 17:10:07 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_PIN_FINAL_TRY: This is the final try before blocking. > * @GNUTLS_PIN_COUNT_LOW: Few tries remain before token blocks. > * @GNUTLS_PIN_WRONG: Last given PIN was not correct. > + * @GNUTLS_PIN_MAY_BE_MISSING: It is fine if the PIN is missing. This patch is messing with the behavior of how the callback is invoked. If I didn't introduce this flag the pin handler in certtool would currently exit() if there was not environment variable set to get the PIN from (GNUTLS_PIN or GNUTLS_SO_PIN). So with this flag I say it's ok if there's no such environment variable and please don't exit(). The root of the problem is that the interface from certtool into the library is missing parameters to set the SRK and key passwords. So the library has to pass srk_password NULL once the srk_password is in a functions parameter list, but NULL may map into the 'well known' password of 20 zero bytes, which may or may not be what the user wants. In case the SRK password is indeed the 20 zero bytes the PIN callback should not return a different password, so the user has to have GNUTLS_PIN unset (which is a behavior change as well). In case it is a string password that invocation of the PIN callback should return the SRK string password from the environment variable. Invoking the PIN callback before doing the first key operation intends to avoid authentication failures with the TPM, which may lock down the TPM and have it refuse operations that require authentication. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116246528 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 18:29:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 17:29:47 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: If there aren't any other tools out there that are affected by the behavioral change in how the PIN callback is invoked, I think it wouldn't matter. People now just have to make sure to unset GNUTLS_PIN when using a well known SRK password, which is the behavioral change for certtool. I have a test case for all of this in the `swtpm` project but tpmtool and certtool are invoked by the tools there rather being explicitly on the command line: https://github.com/stefanberger/swtpm/blob/master/tests/test_samples_create_tpmca I could try to build a similar test case derived from this for GnuTLS where we could set up `tcsd` (TrouSerS) to talk to `swtpm` over a socket and tpmtool creating keys and certtool doing operations with the keys. Then vary what passwords we are using. FYI: There's one more problem that I am aware of and haven't been able to fix (and haven't filed a bug for). It's related to a new key's password. Basically one has to supply two passwords when creating a key, one for the SRK and one for the key itself (child of SRK). However, when one creates the key, the SRK password is needed and then somehow the two passwords get mixed up. So I end up having to use the same password for the key and the SRK. It could be a tcsd design issue where the passwords are put into a cookie jar and the first password is taken out when a password is needed and then when another password is needed the next cookie is taken out... Somehow the passwords are not properly associate with the intended keys. So I end up always using --register with tpmtool, which doesn't need that key password but only the SRK password. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116247776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 19:41:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 18:41:01 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Looks okay to me. Tested 1. make dist from GIT, and 2. configure/make/make install both for in- and for out-of-tree builds with and without local autogen for the respective generated dist-tarballs -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_116252250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 19:41:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 18:41:14 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Merge Request !793 was approved by Andreas Metzler Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/793 Project:Branches: GostCrypt/gnutls:args-std-def to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 20:12:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 19:12:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Substitute src/args-std.def via configure run (!754) In-Reply-To: References: Message-ID: Merge Request !754 was closed by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/754 Branches: tmp-substitution to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/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 Sat Nov 10 20:13:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 19:13:34 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Thanks for working on this and for testing. Closed !754 in favor of this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793#note_116254488 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 20:13:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 19:13:46 +0000 Subject: [gnutls-devel] GnuTLS | src: args-std.def: substitute variables using configure (!793) In-Reply-To: References: Message-ID: Merge Request !793 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/793 Project:Branches: GostCrypt/gnutls:args-std-def to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/793 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 20:13:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 19:13:57 +0000 Subject: [gnutls-devel] GnuTLS | @VERSION@ not replaced in src/args-std.def (#567) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #567: https://gitlab.com/gnutls/gnutls/issues/567 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/567 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 10 23:45:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 10 Nov 2018 22:45:59 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) References: Message-ID: New Issue was created. Issue 613: https://gitlab.com/gnutls/gnutls/issues/613 Author: Dilyan Palauzov Assignee: The [DKIM base specification](https://tools.ietf.org/html/rfc6376#section-3.6.1) states for the k= flag ?The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" tag.". The p= flag is a single, base64 encoded string. The key-data is imported using [gnutls_pubkey_import](https://www.gnutls.org/manual/html_node/Abstract-key-API.html#gnutls_005fpubkey_005fimport). * Write in the documentation that gnutls_pubkey_import deals with ASN.1 data [RFC8463 extends](https://tools.ietf.org/html/rfc8463#section-4.2) the base DKIM specification: ?The p= value in the key record is the Ed25519 public key encoded in base64.? Passing the ed25519 key over gnutls_pubkey_import returns -73 (GNUTLS_E_ASN1_TAG_ERROR) in _asn1_strict_der_decode(), with the key from DNS TXT 201803e._domainkey.kitterman.com . As RFC 8463 doesn?t say anything about ASN.1 I guess ed25519 is not ASN.1 DER encoded, contrary to RSAPublicKey. What function shall be used to import that data? / How shall the key from DNS be imported into a public key, after the base64 decoding? For gnutls_pubkey_import_ecc_raw() the documentation states ?In EdDSA curves the y parameter will be NULL and the other parameters will be in the native format for the curve.? What are the other parameters? There is only one other parameter - ?x?. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 05:16:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 04:16:55 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) References: Message-ID: New Issue was created. Issue 615: https://gitlab.com/gnutls/gnutls/issues/615 Author: Michael Catanzaro Assignee: ## Description of problem: If TLS 1.2 is in use, and a server connection requires client authentication (`GNUTLS_CERT_REQUIRE` passed to `gnutls_certificate_server_set_request`), and the client connection fails to provide any authentication (by failing to fill in the `pcert`, `pcert_length`, and `pkey` parameters of its `gnutls_certificate_retrieve_function2`), then the call to `gnutls_handshake` will fail with `GNUTLS_E_NO_CERTIFICATE_FOUND`. This is the behavior glib-networking expects. But if TLS 1.3 is in use, the call to `gnutls_handshake` unexpectedly succeeds in the client. The client doesn't receive any error until it later attempts to read from the session. Then the client receives `GNUTLS_E_INVALID_SESSION` and `GNUTLS_E_PUSH_ERROR`. This results in the glib-networking testsuite failing. Is the behavior change expected? Shouldn't the handshake fail, as with TLS 1.2? Or is this different by design? ## Version of gnutls used: gnutls-3.6.4.fc29 Also reproduced with 907086568631afa552baf198496f364307de1220 built from git ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora, also manual build from git ## How reproducible: Steps to Reproduce: * Build glib-networking (instructions tested on Fedora 29): ``` $ sudo dnf builddep glib-networking $ git clone https://gitlab.gnome.org/GNOME/glib-networking.git $ mkdir -p glib-networking/build $ cd glib-networking/build $ meson .. $ ninja ``` * Run the testsuite: ``` $ ninja test ``` ## Actual results: ``` 5/6 connection-gnutls FAIL 1.02 s (killed by signal 6 SIGABRT) --- command --- G_TEST_SRCDIR='/home/mcatanzaro/glib-networking/tls/tests' GIO_MODULE_DIR='/home/mcatanzaro/glib-networking/build/tls/gnutls' G_TEST_BUILDDIR='/home/mcatanzaro/glib-networking/build/tls/tests' /home/mcatanzaro/glib-networking/build/tls/tests/connection-gnutls --- stdout --- /tls/connection/basic: OK /tls/connection/verified: OK /tls/connection/verified-chain: OK /tls/connection/verified-chain-with-redundant-root-cert: OK /tls/connection/verified-chain-with-duplicate-server-cert: OK /tls/connection/verified-unordered-chain: OK /tls/connection/verified-chain-with-alternative-ca-cert: OK /tls/connection/invalid-chain-with-alternative-ca-cert: OK /tls/connection/client-auth: OK /tls/connection/client-auth-rehandshake: OK /tls/connection/client-auth-failure: --- stderr --- ** GLib-Net:ERROR:../tls/tests/connection.c:437:on_client_connection_close_finish: assertion failed (error == NULL): Error sending data: Broken pipe (g-io-error-quark, 44) ------- Full log written to /home/mcatanzaro/glib-networking/build/meson-logs/testlog.txt FAILED: meson-test /usr/bin/meson test --no-rebuild --print-errorlogs ninja: build stopped: subcommand failed. ``` The test `/tls/connection/client-auth-failure` fails inside `on_client_connection_close_finish`, a function that is not expected to be reached during this test. The test expects the connection to fail earlier, during the handshake stage. The test succeeds with TLS 1.3 disabled: ``` $ G_TLS_GNUTLS_PRIORITY="@SYSTEM:-VERS-TLS1.3" ninja test ``` Or: ``` $ G_TLS_GNUTLS_PRIORITY="NORMAL:-VERS-TLS1.3" ninja test ``` ## Expected results: The call to `gnutls_handshake` should fail with `GNUTLS_E_NO_CERTIFICATE_FOUND`, allowing `/tls/connection/client-auth-failure` to pass. (Right?) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 07:55:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 06:55:46 +0000 Subject: [gnutls-devel] GnuTLS | Merge branch 'args-std-def' into 'master' (90708656) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on src/Makefile.am: > touch $@ > > cli-args.h: cli-args.stamp > cli-args.c: cli-args.stamp > -cli-args.stamp: $(srcdir)/cli-args.def $(srcdir)/args-std.def > +cli-args.stamp: $(srcdir)/cli-args.def args-std.def > -$(AUTOGEN) $< > + -$(srcdir)/args-bak-upd.sh $@ $(srcdir) > touch $@ > > serv-args.h: serv-args.stamp > serv-args.c: serv-args.stamp > -serv-args.stamp: $(srcdir)/serv-args.def $(srcdir)/args-std.def > +serv-args.stamp: $(srcdir)/serv-args.def args-std.def > -$(AUTOGEN) $< > touch $@ Is it intentional that `args-bak-upd.sh` is not called here? Otherwise I will add it in: https://gitlab.com/gnutls/gnutls/merge_requests/775/diffs?commit_id=3787e547859f2d949f32d3088e080843fddb3fde -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/907086568631afa552baf198496f364307de1220#note_116278101 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:03:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:03:28 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: @nmav I have added a new API (`gnutls_db_entry_is_expired`); would you take a quick look at it? The relevant commit is: https://gitlab.com/gnutls/gnutls/merge_requests/775/diffs?commit_id=33169cc0d8510a95347771cd72d2f1dd669b991a -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116278326 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:35:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:35:28 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: verify whether certificate request levels behave consistently (!799) References: Message-ID: New Merge Request !799 https://gitlab.com/gnutls/gnutls/merge_requests/799 Branches: tmp-cert-status to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Enhance the test suite for the behavior of `gnutls_certificate_server_set_request`, across protocols. ## Checklist * [x] Test suite updated with functionality 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/799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:39:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:39:55 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: This is correct. I tried to make a reproducer with https://gitlab.com/gnutls/gnutls/commit/414b14d922e44e442cb86947ea77319cdcd796d9 but it succeed on git master (the expected error code is returned). Are you sure than in that test suite you refer, the handshake is fully completed on both sides (i.e., `gnutls_handshake` returns zero)? That was a common issue in test suites and tls1.3. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116279408 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:54:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:54:20 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: > The [DKIM base specification](https://tools.ietf.org/html/rfc6376#section-3.6.1) states for the k= flag ?The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" tag.". The p= flag is a single, base64 encoded string.? The key-data is imported using [gnutls_pubkey_import](https://www.gnutls.org/manual/html_node/Abstract-key-API.html#gnutls_005fpubkey_005fimport). > - Write in the documentation that gnutls_pubkey_import deals with ASN.1 data > [RFC8463 extends](https://tools.ietf.org/html/rfc8463#section-4.2) the base DKIM specification: ?The p= value in the key record is the Ed25519 public key encoded in base64.? Hi, All gnutls import and export functions deal with X.509 (ASN-encoded) data. In particular `gnutls_pubkey_import` is documented to import a `SubjectPublicKeyInfo X.509 structure`, and not the structures described in RFC8463. Note also that gnutls doesn't claim to implement RFC8463. > What function shall be used to import that data? / How shall the key from DNS be imported into a public key, after the base64 decoding? RFC8463 seems to be using raw keys, and thus you'd need to use `gnutls_pubkey_import_ecc_raw`. You may want to see how the knot dns guys have implemented that part. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116279842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:55:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:55:04 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: Closing as this is not an issue for gnutls per se. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116279862 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 08:55:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 07:55:05 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #613: https://gitlab.com/gnutls/gnutls/issues/613 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 09:04:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 08:04:11 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: If the parametes is only ?x? then the documentation of gnutls_pubkey_import_ecc_raw shall be updated to state > In EdDSA curves the y parameter will be NULL and the other parameter will be in the native format for the curve. replacing parameters ? parameter, or even > In EdDSA curves the y parameter will be NULL and the x parameter will be in the native format for the curve. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116280155 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 09:04:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 08:04:46 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: I like it. It looks like a more usable version of the existing APIs. We may want to test it at the same places where we use `gnutls_db_check_entry_time` and for anti replay. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116280163 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 09:09:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 08:09:56 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: btw. if the application had the option to flush the anti-reply database how could it decide the right moment to do it? Is it ok for an application to flush this db every few minutes/hours or so? I checked more about memcached and how it could use this feature, and it has a flush command which erases everything in the db, so the above may be a question we may see. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116280356 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 09:23:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 08:23:20 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: The structures described in RFC8463 in fact reference RFC8032, see https://tools.ietf.org/html/rfc8463#appendix-A.2 . I asked how to import the structures from RFC8032, after calling gnutls_pubkey_import_ecc_raw with y=NULL and x with the base64 decoded data lead to crash. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116280834 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 10:10:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 09:10:01 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: I think the flush command is usable only if all the database accesses are synchronized and the flush interval matches the anti-replay window. Otherwise, the timing gap could cause removal of a newly added entry that is not expired. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116282489 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 10:27:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 09:27:12 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: The abstract of [RFC8463](https://tools.ietf.org/html/rfc8463#appendix-A.2) speaks about Ed25519-SHA256. Calling gnutls_pk_to_sign(GNUTLS_PK_EDDSA_ED25519, gnutls_digest_algorithm_t hash) I have to pass hash=GNUTLS_DIG_SHA512, otherwise gnutls_pk_to_sign returns GNUTLS_SIGN_UNKNOWN. I want to use SHA256 with ED25519, which seems to me impossible. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116283205 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 12:08:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 11:08:25 +0000 Subject: [gnutls-devel] GnuTLS | Merge branch 'args-std-def' into 'master' (90708656) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on src/Makefile.am: > libcmd_systemkey_la_LIBADD = ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la > libcmd_systemkey_la_LIBADD += $(LTLIBREADLINE) $(INET_PTON_LIB) $(LIB_CLOCK_GETTIME) > > danetool-args.h: danetool-args.stamp > danetool-args.c: danetool-args.stamp > -danetool-args.stamp: $(srcdir)/danetool-args.def $(srcdir)/args-std.def > +danetool-args.stamp: $(srcdir)/danetool-args.def args-std.def > -$(AUTOGEN) $< > touch $@ > > ocsptool-args.h: ocsptool-args.stamp > ocsptool-args.c: ocsptool-args.stamp > -ocsptool-args.stamp: $(srcdir)/ocsptool-args.def $(srcdir)/args-std.def > +ocsptool-args.stamp: $(srcdir)/ocsptool-args.def args-std.def > -$(AUTOGEN) $< > + -$(srcdir)/args-bak-upd.sh $@ $(srcdir) I see errors with 'make distcheck' when $(srcdir) is read-only. Shouldn't it be $(builddir) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/907086568631afa552baf198496f364307de1220#note_116288523 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 12:14:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 11:14:40 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: The documentation of gnutls_privkey_sign_hash() says: ?Note that, not all algorithm support signing already hashed data. When signing with Ed25519, gnutls_privkey_sign_data() should be used.?, but this is not stated for gnutls_pubkey_verify_hash2() at https://www.gnutls.org/manual/html_node/Operations.html#Operations. [RFC6376](https://tools.ietf.org/html/rfc6376#section-5.5) says ?The Signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm.? For me this means, that not the data, but the hash must signed, so gnutls_privkey_sign_hash() and gnutls_pubkey_verify_hash2() must be used. They do work correctly, when RSA is used for signing/verifying the hash at this place. gnutls_pubkey_verify_hash2() calls _gnutls_pk_is_not_prehashed() which fails for ed25519. How shall the requirement to sign the hash from RFC6376 be implemented in GnuTLS for Ed25519, as presented in RFC8463? In particular which function shall verify the signature of the signed hash? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116288836 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 16:09:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 15:09:08 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > Are you sure than in that test suite you refer, the handshake is fully completed on both sides (i.e., `gnutls_handshake` returns zero)? It's completed successfully on the client side if TLS 1.3 is used. (With TLS 1.2, if fails with `GNUTLS_E_NO_CERTIFICATE_FOUND`.) On the server side, it fails with `GNUTLS_E_NO_CERTIFICATE_FOUND`. > That was a common issue in test suites and tls1.3. Also are there any special flags used with `gnutls_init`? Just `GNUTLS_CLIENT` or `GNUTLS_SERVER`. > I'd really appreciate a reproducer which uses gnutls directly. I think your test is checking the result of `gnutls_handshake` in the server, not the client. Maybe I wasn't clear enough that the unexpected behavior occurs only on the client side. Let me try modifying it to see what happens. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116306371 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 16:45:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 15:45:43 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > I think your test is checking the result of `gnutls_handshake` in the server, not the client. Maybe I wasn't clear enough that the unexpected behavior occurs only on the client side. Let me try modifying it to see what happens. I modified your `cert-status` test to print the handshake result of the client. With TLS 1.0 and TLS 1.2, the client's `gnutls_handshake` fails with `GNUTLS_E_PULL_ERROR`. (I don't know why that differs from the `GNUTLS_E_NO_CERTIFICATE_FOUND` that glib-networking receives and expects, but perhaps it's because glib-networking uses its own custom push and pull functions.) With TLS 1.3, the client's `gnutls_handshake` succeeds (unexpectedly?). https://gitlab.com/TheRealMichaelCatanzaro/gnutls/commit/7ea1fa1c405643ff41c51e10346c0c307465770a demonstrates this behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116308847 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 19:50:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 18:50:34 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Aha. Unfortunately, there is not much we can do for that. The TLS1.3 handshake is: ``` Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] ``` meaning that the client has seen the client finished before he sends his certificate. That is, the server has no way to indicate rejection of the session due to certificate in the normal handshake, thus `gnutls_handshake()` for the client will not see that error. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116321087 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 20:05:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 19:05:14 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: OK, thanks. I'll figure out how to change glib-networking's expectations, then. > Any suggestion on how/where we can document that? I'd just mention this in the documentation of `gnutls_handshake`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116321922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 20:06:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 19:06:18 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: (*Only mildly related*: the next bug I'm working on is that the `gnutls_certificate_verify_function` set by `gnutls_session_set_verify_function` is sometimes not called during the call to `gnutls_handshake`, with all versions of TLS. I'm just now starting to dive in deeper to figure out why. Is there any situation where that might be expected to happen for some reason?) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116321967 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 20:31:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 19:31:02 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Issue was closed by Michael Catanzaro Issue #615: https://gitlab.com/gnutls/gnutls/issues/615 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 20:48:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 19:48:32 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > _Only mildly related_: the next bug I'm working on It's session resumption... it's unrelated, so I'll let you know elsewhere if I can't figure it out. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116324516 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 11 21:34:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 20:34:51 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: - 4.5 uses BER indefinite-length encoding for `encapContentInfo.eContent`, which fails to be parsed using `asn1_get_length_der()`. Replacing it with `asn1_get_length_ber()` results in signature verification failure. - 4.6 second signature uses certificate with DSS parameters inherited from parent certificate rather than specified in certificate itself (there are huge FIXMEs in `_gnutls_x509_read_dsa_params()` and `_gnutls_get_asn_mpis()`). @nmav any idea how to handle this in the graceful way? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612#note_116327601 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 00:12:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 23:12:05 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > OK, thanks. I'll figure out how to change glib-networking's expectations, then. Actually, would it be possible to get the `GNUTLS_E_NO_CERTIFICATE_FOUND` on the client side somehow (perhaps if the GnuTLS server would send an alert?) or is it just not possibly to reliably detect why the server has rejected the connection in this case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116339012 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 00:38:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 11 Nov 2018 23:38:30 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Pushed https://gitlab.gnome.org/GNOME/glib-networking/commit/572ad13459c826e8ebfa730e4b040fc4d7d38e4f to glib-networking. You can see it's... not great... but it's hard to maintain the original API behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116340388 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 01:33:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 00:33:11 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: 4.5 can be fixed with the following patch. According to CMS spec BER is allowed there: ```diff diff --git a/lib/x509/pkcs7.c b/lib/x509/pkcs7.c index 955cb5ae9cce..e6e40ead26fb 100644 --- a/lib/x509/pkcs7.c +++ b/lib/x509/pkcs7.c @@ -111,7 +111,7 @@ static int _decode_pkcs7_signed_data(gnutls_pkcs7_t pkcs7) /* Try reading as octet string according to rfc5652. If that fails, attempt * a raw read according to rfc2315 */ - result = _gnutls_x509_read_string(c2, "encapContentInfo.eContent", &pkcs7->der_signed_data, ASN1_ETYPE_OCTET_STRING, 0); + result = _gnutls_x509_read_string(c2, "encapContentInfo.eContent", &pkcs7->der_signed_data, ASN1_ETYPE_OCTET_STRING, 1); if (result < 0) { result = _gnutls_x509_read_value(c2, "encapContentInfo.eContent", &pkcs7->der_signed_data); if (result < 0) { ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612#note_116342741 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 08:21:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 07:21:45 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Would it be possible to pass make the expected expiry time available to the application using GnuTLS? The Apache socache modules implement expiry by themselves, so it would be better to set the expiry time expected by GnuTLS when storing the entry. Looking at the patches a function that operates on the entry data `gnutls_datum_t` could do that without changing the API. Implementing `gnutls_db_set_add_function` with socache will be tricky using socache, but having an atomic add function could be an option to share a ticket key across a cluster of servers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116377516 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 09:19:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 08:19:10 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: It seems the user friendliness of the (default) client certificate authentication was not prioritized in the TLS working group. They focused on the post-handshake authentication instead which provides a more natural way for it. Could glib-networking rely on that for tls1.3? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116393518 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 12:08:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 11:08:14 +0000 Subject: [gnutls-devel] =?utf-8?q?GnuTLS_=7C_=2E/configure_printing_?= =?utf-8?b?4oCcU2VzLiB0aWNrZXQgc3VwcG9ydOKAnSAoIzYxNik=?= References: Message-ID: New Issue was created. Issue 616: https://gitlab.com/gnutls/gnutls/issues/616 Author: Dilyan Palauzov Assignee: Commit d9ce82a4 introduced the possibility to disable session tickets, and added the ENABLE_SESSION_TICKETS macro with the ?Ses. ticket support? configure?s summary with the corresponding checks in m4/hooks.m4. Commit 4b5678716 removed reverted the changes in m4/hooks.m4, leaving the configure?s summary unchanged, that is printing a ?Ses. ticket support:? line without text after the colon. ```diff diff --git a/configure.ac b/configure.ac index 2a36a6ed8..81c834dac 100644 --- a/configure.ac +++ b/configure.ac @@ -1049,7 +1049,6 @@ if features are disabled) DTLS-SRTP support: $ac_enable_srtp ALPN support: $ac_enable_alpn OCSP support: $ac_enable_ocsp - Ses. ticket support: $ac_enable_session_tickets SRP support: $ac_enable_srp PSK support: $ac_enable_psk DHE support: $ac_enable_dhe ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 13:04:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 12:04:05 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: > Would it be possible to pass make the expected expiry time available to the application using GnuTLS? The Apache socache modules implement expiry by themselves, so it would be better to set the expiry time expected by GnuTLS when storing the entry Good point, thank you. I have replaced `gnutls_db_entry_is_expired` with the new function `gnutls_db_check_entry_expire_time` that returns expiry time instead of a boolean. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_116458250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 15:36:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 14:36:09 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Fix memory leak in encode_tpmkey_url (!800) References: Message-ID: New Merge Request !800 https://gitlab.com/gnutls/gnutls/merge_requests/800 Project:Branches: stefanberger/gnutls:tpm12_fix_memory_leak to gnutls/gnutls:master Author: Stefan Berger Assignee: This patch fixes a memory leak in the encode_tpmkey_url function. Stefan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/800 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:39:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:39:14 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: Looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794#note_116552344 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:39:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:39:17 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: Merge Request !794 was approved by Jakub Jelen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/794 Branches: tmp-f29 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:41:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:41:43 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: Merge Request !794 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/794 Branches: tmp-f29 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:41:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:41:49 +0000 Subject: [gnutls-devel] GnuTLS | update CI to fedora29 (#607) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #607: https://gitlab.com/gnutls/gnutls/issues/607 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:41:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:41:50 +0000 Subject: [gnutls-devel] GnuTLS | update CI to fedora29 (#607) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #607: https://gitlab.com/gnutls/gnutls/issues/607 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:41:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:41:51 +0000 Subject: [gnutls-devel] GnuTLS | .gitlab-ci.yml: move to fedora29 for CI (!794) In-Reply-To: References: Message-ID: Merge Request !794 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/794 Branches: tmp-f29 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/794 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 16:54:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:54:04 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Merge Request !775 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/775 Branches: tmp-0rtt 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/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 Mon Nov 12 16:54:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 15:54:03 +0000 Subject: [gnutls-devel] GnuTLS | Add support for TLS 1.3 Zero-RTT Data (#127) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #127: https://gitlab.com/gnutls/gnutls/issues/127 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/127 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 17:03:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 16:03:49 +0000 Subject: [gnutls-devel] GnuTLS | WIP: build: remove autogen .bak files from repository (!801) References: Message-ID: New Merge Request !801 https://gitlab.com/gnutls/gnutls/merge_requests/801 Branches: tmp-autogen-bak to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list While the .bak files are necessary for not requiring autogen on deployment environment, they are not needed for development and may cause conflict when other developers use different version of autogen. This removes those files from the repository and require autogen at `make dist` time. ## Checklist * [ ] 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/801 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 12 17:12:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 12 Nov 2018 16:12:52 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: I have a bug report for it here: https://gitlab.gnome.org/GNOME/glib-networking/issues/39 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_116561832 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 06:04:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 05:04:08 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: Thank you for finding the issue. The existing support for PKCS#7 is mostly pre-CMS, and the newer additions focused on microsoft generated (cat) files. It would be certainly good to make that more generic and support the structures from rfc4134. About the 4.6, I wouldn't really bother fixing because (1) such certificates were never used in practice, (2) DSA is an obsolete algorithm. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612#note_116722786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 06:07:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 05:07:00 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Fix memory leak in encode_tpmkey_url (!800) In-Reply-To: References: Message-ID: Merge Request !800 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/800 Project:Branches: stefanberger/gnutls:tpm12_fix_memory_leak to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/800 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 06:07:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 05:07:02 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Fix memory leak in encode_tpmkey_url (!800) In-Reply-To: References: Message-ID: Merge Request !800 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/800 Project:Branches: stefanberger/gnutls:tpm12_fix_memory_leak to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/800 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 06:07:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 05:07:13 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Fix memory leak in encode_tpmkey_url (!800) 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/800#note_116723106 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 06:16:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 05:16:39 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: > I have a test case for all of this in the `swtpm` project but tpmtool and certtool are invoked by the tools there rather being explicitly on the command line: https://github.com/stefanberger/swtpm/blob/master/tests/test_samples_create_tpmca > I could try to build a similar test case derived from this for GnuTLS where we could set up `tcsd` (TrouSerS) to talk to `swtpm` over a socket and tpmtool creating keys and certtool doing operations with the keys. Then vary what passwords we are using. I think that would be great to have some basic coverage. Is the swtpm something we should bring in the f29 CI? (now merged) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116724083 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 09:10:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 08:10:01 +0000 Subject: [gnutls-devel] GnuTLS | Getting error "Please insert token 'TEE_TOKEN' in slot and press enter" on searching private objects. (#583) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/583 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 09:10:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 08:10:49 +0000 Subject: [gnutls-devel] GnuTLS | update CI to fedora29 (#607) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 09:17:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 08:17:19 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: > If the parametes is only ?x? then the documentation of gnutls_pubkey_import_ecc_raw shall be updated to state I agree it makes sense. I've sent a potential update of this text as part of !799. Feel free to open pull requests with documentation updates. > [RFC6376](https://tools.ietf.org/html/rfc6376#section-5.5) says ?The Signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm.? > gnutls_pubkey_verify_hash2() calls _gnutls_pk_is_not_prehashed() which fails for ed25519. > How shall the requirement to sign the hash from RFC6376 be implemented in GnuTLS for Ed25519, as presented in RFC8463? In particular which function shall verify the signature of the signed hash? This text cannot literally apply to ed25519 because it is designed to directly hash the data (hashing with sha512 is part of the signature). How it applies to the rfcs you describe is something I do not know. I know however that the knotdns guys have already implemented that part using gnutls, so I'd recommend to check how they have done it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116752598 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 09:27:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 08:27:16 +0000 Subject: [gnutls-devel] GnuTLS | Gost raw privkeys (!802) References: Message-ID: New Merge Request !802 https://gitlab.com/gnutls/gnutls/merge_requests/802 Project:Branches: GostCrypt/gnutls:gost-raw-privkeys to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## 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/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 09:28:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 08:28:40 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: @nmav do I need to document somehow new `certool --pkcs-cipher none` option? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_116755195 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 11:29:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 10:29:06 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: @dueno I'd suggest to extend distcheck test by compiling tarball contents with AUTOGEN override so that we can be sure that tarball is buildable on systems without autogen. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116816839 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 11:35:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 10:35:30 +0000 Subject: [gnutls-devel] GnuTLS | tests: verify whether certificate request levels behave consistently (!799) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/privkey_raw.c: > * gnutls_privkey_export_ecc_raw: > * @key: Holds the public key > * @curve: will hold the curve > - * @x: will hold the x coordinate > - * @y: will hold the y coordinate > + * @x: will hold the x-coordinate > + * @y: will hold the y-coordinate These updates also apply to gost pubic key import/export functions. Would you change them or would you like me to do it after you merge this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_116819137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 11:44:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 10:44:26 +0000 Subject: [gnutls-devel] GnuTLS | tests: verify whether certificate request levels behave consistently (!799) In-Reply-To: References: Message-ID: I don't seem to be able to reproduce `pubkey-import-export` failure on my box. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_116822137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 13:25:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 12:25:35 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: @lumag thank you, I have added `AUTOGEN=false` to `DISTCHECK_CONFIGURE_FLAGS`, ... and it indeed detected a mistake :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116851923 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:18:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:18:11 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: @dueno also I missed in previous review that there is no `.h.h.bak` rule. Is it by purpose? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116866021 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:19:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:19:47 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: Also .h.bak files also can be removed, can't they? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116867786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:22:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:22:01 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: LGTM otherwise -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116868400 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:28:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:28:22 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) References: Message-ID: New Merge Request !803 https://gitlab.com/gnutls/gnutls/merge_requests/803 Project:Branches: GostCrypt/gnutls:pkcs7-ber to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality 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/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:44:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:44:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Reassigned Merge Request 803 https://gitlab.com/gnutls/gnutls/merge_requests/803 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:44:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:44:35 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Would you like to add the test case that triggered that issue? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_116875072 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 14:54:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 13:54:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: @nmav yes, that's why MR is marked as WIP. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_116878966 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:08:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:08:09 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: I think we should bring it in once its available in F29. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_116885012 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:18:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:18:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Oh, sorry. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_116888281 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:18:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:18:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Reassigned Merge Request 803 https://gitlab.com/gnutls/gnutls/merge_requests/803 Assignee changed from Nikos Mavrogiannopoulos to Unassigned -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:21:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:21:50 +0000 Subject: [gnutls-devel] GnuTLS | WIP: pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Reassigned Merge Request 803 https://gitlab.com/gnutls/gnutls/merge_requests/803 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:24:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:24:58 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: LGTM now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116890362 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:26:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:26:04 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: @lumag, thank you for the review; let's see how CI goes... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_116890674 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:30:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:30:23 +0000 Subject: [gnutls-devel] GnuTLS | tests: verify whether certificate request levels behave consistently (!799) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/privkey_raw.c: > * gnutls_privkey_export_ecc_raw: > * @key: Holds the public key > * @curve: will hold the curve > - * @x: will hold the x coordinate > - * @y: will hold the y coordinate > + * @x: will hold the x-coordinate > + * @y: will hold the y-coordinate I'll do. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_116892003 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:51:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:51:40 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: During the standartization process of RFC8463, this message discussed ED25519 signing of hashes, rather than the whole message data https://www.ietf.org/mail-archive/web/dcrup/current/msg00501.html, citing from the GnuTLS manual ?Note that, not all algorithm support signing already hashed data. When signing with Ed25519, gnutls_privkey_sign_data() should be used.? The answer https://www.ietf.org/mail-archive/web/dcrup/current/msg00502.html contains: ?if the spec says there's a pure version that doesn't hash its input, the libraries would implement it?. Now the common aim is, that libraries implement what specifications say. I am not in a position to lead a fact based discussion on Ed25519 signing hashes, as I am not that competent in cryptography. Neither is it feasible to make postings to a mailing list, then (filter and) copy the answers here, and then back to the mailing list. If RFC8463 says to sign hashes with ED25519 and GnuTLS is not going to sign ED25519 hashes, please subscirbe either the DCRUP / https://www.ietf.org/mailman/listinfo/dcrup or the IETF-DKIM / https://www.ietf.org/mailman/listinfo/ietf-dkim mailing lists and reach a consent. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_116900727 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 15:51:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 14:51:43 +0000 Subject: [gnutls-devel] GnuTLS | Importing ED25519 in pubkey (#613) In-Reply-To: References: Message-ID: Issue was reopened by Dilyan Palauzov Issue 613: https://gitlab.com/gnutls/gnutls/issues/613 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 18:12:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 17:12:52 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 22:30:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 21:30:45 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: Merge Request !801 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/801 Branches: tmp-autogen-bak to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 22:31:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 21:31:34 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: The CI image used in gnutls should contain it already. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_117034660 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 22:56:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 21:56:42 +0000 Subject: [gnutls-devel] GnuTLS | tests: verify whether certificate request levels behave consistently (!799) In-Reply-To: References: Message-ID: Not sure about it. I also thought it succeeded on a local run, but CI caught it. There was no check for the public keys, and I've now added it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_117039148 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 23:06:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 22:06:36 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: @nmav I'd like to merge this if you don't have any objections. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_117040455 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 23:06:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 22:06:42 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Note that there is a more transparent and easy way to do it with 3.6.5 (see !766) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117040466 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 23:45:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 22:45:34 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: @nmav added test data from RFC 4134. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_117047524 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 13 23:58:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 22:58:50 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: drop obsolete info line (!804) References: Message-ID: New Merge Request !804 https://gitlab.com/gnutls/gnutls/merge_requests/804 Project:Branches: GostCrypt/gnutls:no-session-ticket to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [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/804 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 00:04:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 13 Nov 2018 23:04:36 +0000 Subject: [gnutls-devel] =?utf-8?q?GnuTLS_=7C_=2E/configure_printing_?= =?utf-8?b?4oCcU2VzLiB0aWNrZXQgc3VwcG9ydOKAnSAoIzYxNik=?= In-Reply-To: References: Message-ID: Reassigned Issue 616 https://gitlab.com/gnutls/gnutls/issues/616 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:15:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:15:37 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on src/Makefile.am: > systemkey-args.stamp: args-std.def > > mech-list.h: gen-mech-list.sh > - @$(srcdir)/gen-mech-list.sh > mech-list.h.tmp > - @mv mech-list.h.tmp $@ > - > -maintainer-clean-local: > - rm -f *.stamp mech-list.h Is the removal of this line intentional? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801#note_117123981 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:16:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:16:12 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: drop obsolete info line (!804) In-Reply-To: References: Message-ID: Merge Request !804 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/804 Project:Branches: GostCrypt/gnutls:no-session-ticket to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/804 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:16:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:16:21 +0000 Subject: [gnutls-devel] =?utf-8?q?GnuTLS_=7C_=2E/configure_printing_?= =?utf-8?b?4oCcU2VzLiB0aWNrZXQgc3VwcG9ydOKAnSAoIzYxNik=?= In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #616: https://gitlab.com/gnutls/gnutls/issues/616 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:16:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:16:26 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: drop obsolete info line (!804) In-Reply-To: References: Message-ID: Merge Request !804 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/804 Project:Branches: GostCrypt/gnutls:no-session-ticket to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/804 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:16:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:16:22 +0000 Subject: [gnutls-devel] =?utf-8?q?GnuTLS_=7C_=2E/configure_printing_?= =?utf-8?b?4oCcU2VzLiB0aWNrZXQgc3VwcG9ydOKAnSAoIzYxNik=?= In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #616: https://gitlab.com/gnutls/gnutls/issues/616 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:18:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:18:52 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/x509/privkey_pkcs8.c: > { > int ret; > > - if (raw_key->data[0] == ASN1_TAG_INTEGER) { > + if (raw_key->size % 32 == 0) { why this modulo operation? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117124647 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:20:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:20:27 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Reassigned Merge Request 802 https://gitlab.com/gnutls/gnutls/merge_requests/802 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:21:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:21:52 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/x509/privkey_pkcs8.c: > case GNUTLS_PK_GOST_01: > case GNUTLS_PK_GOST_12_256: > case GNUTLS_PK_GOST_12_512: > - if ((ret = asn1_create_element Should we reference some document to justify why we are doing that? What are the advantages of this form? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117125249 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:23:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:23:14 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pkcs8-gost: > +#!/bin/sh > + > +# Copyright (C) 2018 Dmitry Eremin-Solenikov > +# Copyright (C) 2004-2006, 2010, 2012 Free Software Foundation, Inc. > +# > +# Author: Simon Josefsson I think we should change the author -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117125588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:24:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:24:27 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Except the questions above it looks good to me. We will need a NEWS entry as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117125846 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:24:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:24:52 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert description in Alert Message (#618) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:26:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:26:16 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS continue in a conversation when second ClienHello is different than the first CH, in HRR. (#617) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/617 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:27:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:27:33 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS continue in a conversation when second ClienHello is different than the first CH, in HRR. (#617) In-Reply-To: References: Message-ID: Thank you Robert for bringing that up. Is that the issue we discussed at: https://github.com/tomato42/tlsfuzzer/issues/398 If yes, I think my reply to that is still relevant, and I'm not sure we want to address it. Quoting below > To add some context this test is about the https://tools.ietf.org/html/rfc8446#section-4.1.2 requirement: ``` The client will also send a ClientHello when the server has responded to its ClientHello with a HelloRetryRequest. In that case, the client MUST send the same ClientHello without modification, except as follows: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.10) if one was present. Early data is not permitted after a HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. - Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite. - Optionally adding, removing, or changing the length of the "padding" extension [RFC7685]. - Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest. ``` > So that's a nice test to verify whether the server enforces that behavior (like tlslite-ng), but since the MUST is on the client to follow the rules, and not on the server to enforce, both behaviors look acceptable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/617#note_117126565 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:29:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:29:01 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: All discussions on Merge Request !801 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/801 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:29:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:29:19 +0000 Subject: [gnutls-devel] GnuTLS | build: remove autogen .bak files from repository (!801) In-Reply-To: References: Message-ID: Merge Request !801 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/801 Branches: tmp-autogen-bak to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/801 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:36:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:36:25 +0000 Subject: [gnutls-devel] GnuTLS | RFC8463 and signing hashes with ED25519 (#613) In-Reply-To: References: Message-ID: > The answer https://www.ietf.org/mail-archive/web/dcrup/current/msg00502.html contains: ?if the spec says there's a pure version that doesn't hash its input, the libraries would implement it?. GnuTLS implements the standardized version of EdDSA, which is the pure version as defined in [RFC8410](https://tools.ietf.org/html/rfc8410). The pure version can only hash data, and cannot sign an existing hash. The version which can sign arbitrary hashes is called pre-hashed-EdDSA and has not been standardized (at least not in the RFC above). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/613#note_117128641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:41:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:41:45 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS continue in a conversation when second ClienHello is different than the first CH, in HRR. (#617) In-Reply-To: References: Message-ID: Yes, it's about that #398 issue in tlsfuzzer, I forgot about that discussion. We discussed at a mtg, that it would be good to report it, so i did it. If we are not sure if we want to address it, it's up to you to close this issue or keep it open so we know about this "bug". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/617#note_117129821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 09:53:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 08:53:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Is that what you believe is the final version? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117133087 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 10:49:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 09:49:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Autogen prerequisite (!645) In-Reply-To: References: Message-ID: I must admit I completely missed this MR while doing !801, sorry. It seems that this initially covered the following, which I think are still nice to have: - remove `.bak` files from the distribution tarball, and instead include `.c`, `.h`, and `.stamp` files for not requiring autogen on deployment environment - add autogen in bootstrap.conf's prerequisites -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/645#note_117152609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 12:53:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 11:53:01 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pkcs7: > exit ${rc} > fi > > +if test "x$ALLOW_SHA1" = "x1" > +then > + # Test BER encoding, see RFC 4134 Section 4.5 > + FILE="rfc4134-4.5" > + ${VALGRIND} "${CERTTOOL}" --p7-verify --load-ca-certificate "${srcdir}/data/rfc4134-ca-rsa.pem" --infile "${srcdir}/data/rfc4134-4.5.p7b" --inder Why not use `--verify-allow-broken` instead of disabling that test when SHA1 is disallowed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_117191086 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 12:55:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 11:55:26 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on tests/cert-tests/pkcs7: > exit ${rc} > fi > > +if test "x$ALLOW_SHA1" = "x1" > +then > + # Test BER encoding, see RFC 4134 Section 4.5 > + FILE="rfc4134-4.5" > + ${VALGRIND} "${CERTTOOL}" --p7-verify --load-ca-certificate "${srcdir}/data/rfc4134-ca-rsa.pem" --infile "${srcdir}/data/rfc4134-4.5.p7b" --inder In fact I forgot about this swich. Changed now, thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803#note_117191626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 12:55:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 11:55:26 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: All discussions on Merge Request !803 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/803 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 13:05:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 12:05:00 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Merge Request !803 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/803 Project:Branches: GostCrypt/gnutls:pkcs7-ber to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 14:24:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 13:24:00 +0000 Subject: [gnutls-devel] GnuTLS | WIP: updates in anti-replay subsystem (!805) References: Message-ID: New Merge Request !805 https://gitlab.com/gnutls/gnutls/merge_requests/805 Branches: tmp-anti-replay-updates to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi and GnuTLS devel mailing list This adds a higher level unit test of the anti-replay functionality (checks whether an already used entry is detected), and separates the anti-replay database from the TLS1.2 resumption database, as it was on Daiki's original patch for 0rtt. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [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/805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 14:43:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 13:43:05 +0000 Subject: [gnutls-devel] GnuTLS | WIP: updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/tls13/anti_replay.c: > - * gnutls_db_entry_is_expired() work. > + * gnutls_db_check_entry_expire_time() work. > */ > p = entry_buffer; > _gnutls_write_uint32(PACKED_SESSION_MAGIC, p); > p += 4; > _gnutls_write_uint32(now.tv_sec, p); > p += 4; > - _gnutls_write_uint32(anti_replay->window / 1000, p); > + window = anti_replay->window / 1000; > + _gnutls_write_uint32(window, p); > p += 4; > entry.data = entry_buffer; > entry.size = p - entry_buffer; > > - ret = session->internals.db_add_func(session->internals.db_ptr, now that `_gnutls_anti_replay_check` no longer needs `session`, maybe the 1st argument could be `gnutls_anti_replay_t`? That could also simplify `tests/tls13/anti_replay.c` as you don't need to initialize sessions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805#note_117222259 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 14:46:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 13:46:58 +0000 Subject: [gnutls-devel] GnuTLS | WIP: updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/tls13/anti_replay.c: > p = entry_buffer; > _gnutls_write_uint32(PACKED_SESSION_MAGIC, p); > p += 4; > _gnutls_write_uint32(now.tv_sec, p); > p += 4; > - _gnutls_write_uint32(anti_replay->window / 1000, p); > + window = anti_replay->window / 1000; > + _gnutls_write_uint32(window, p); > p += 4; > entry.data = entry_buffer; > entry.size = p - entry_buffer; > > - ret = session->internals.db_add_func(session->internals.db_ptr, > - key, entry); > + ret = anti_replay->db_add_func(anti_replay->db_ptr, > + now.tv_sec+window, &key, &entry); Couldn't `now.tv_sec+window` be overflow (and if `time_t` is signed, it's an undefined behavior)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805#note_117223423 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:01:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:01:54 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/x509/privkey_pkcs8.c: > { > int ret; > > - if (raw_key->data[0] == ASN1_TAG_INTEGER) { > + if (raw_key->size % 32 == 0) { Ack. I will replace this with `gnutls_ecc_curve_get_size()` result. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117228088 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:02:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:02:06 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on tests/cert-tests/pkcs8-gost: > +#!/bin/sh > + > +# Copyright (C) 2018 Dmitry Eremin-Solenikov > +# Copyright (C) 2004-2006, 2010, 2012 Free Software Foundation, Inc. > +# > +# Author: Simon Josefsson ack -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117228160 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:05:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:05:00 +0000 Subject: [gnutls-devel] GnuTLS | pkcs7: allow BER encoding when parsing encapContentInfo.eContent (!803) In-Reply-To: References: Message-ID: Merge Request !803 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/803 Project:Branches: GostCrypt/gnutls:pkcs7-ber to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:26:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:26:40 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) References: Message-ID: New Merge Request !806 https://gitlab.com/gnutls/gnutls/merge_requests/806 Branches: tmp-fix-certificate-type to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list That is, ensure that unless we negotiate something else than X509, the default certificate type is returned to applications. Previously we wouldn't do that for TLS1.3 resumed sessions, and we would return zero (invalid type) instead. That addresses issues with applications checking explicitly for X509 certificate type being present. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:27:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:27:48 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom (@Vrancken ) would you like to check this? It relates with the changes for rfc7250. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117238173 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:31:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:31:28 +0000 Subject: [gnutls-devel] GnuTLS | WIP: updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tls13/anti_replay.c: > - * gnutls_db_entry_is_expired() work. > + * gnutls_db_check_entry_expire_time() work. > */ > p = entry_buffer; > _gnutls_write_uint32(PACKED_SESSION_MAGIC, p); > p += 4; > _gnutls_write_uint32(now.tv_sec, p); > p += 4; > - _gnutls_write_uint32(anti_replay->window / 1000, p); > + window = anti_replay->window / 1000; > + _gnutls_write_uint32(window, p); > p += 4; > entry.data = entry_buffer; > entry.size = p - entry_buffer; > > - ret = session->internals.db_add_func(session->internals.db_ptr, Makes sense. Will update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805#note_117242151 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:37:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:37:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Autogen prerequisite (!645) In-Reply-To: References: Message-ID: NP, maybe you can take the useful (and still missing) things and make up another MR !? I currently don't have the time :-( -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/645#note_117248026 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 15:41:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 14:41:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tls13/anti_replay.c: > p = entry_buffer; > _gnutls_write_uint32(PACKED_SESSION_MAGIC, p); > p += 4; > _gnutls_write_uint32(now.tv_sec, p); > p += 4; > - _gnutls_write_uint32(anti_replay->window / 1000, p); > + window = anti_replay->window / 1000; > + _gnutls_write_uint32(window, p); > p += 4; > entry.data = entry_buffer; > entry.size = p - entry_buffer; > > - ret = session->internals.db_add_func(session->internals.db_ptr, > - key, entry); > + ret = anti_replay->db_add_func(anti_replay->db_ptr, > + now.tv_sec+window, &key, &entry); casted them to uint64_t. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805#note_117250905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:11:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:11:48 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: tpm: Add a test case for tpmtool (!807) References: Message-ID: New Merge Request !807 https://gitlab.com/gnutls/gnutls/merge_requests/807 Project:Branches: stefanberger/gnutls:tpm12_testing to gnutls/gnutls:master Author: Stefan Berger Assignee: This adds a test case for using the TPM via tpmtool. We setup a local TPM emulator using swtpm and make tcsd use it. Tpmtool then talks to the swtpm via tcsd. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:39:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:39:02 +0000 Subject: [gnutls-devel] GnuTLS | updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: All discussions on Merge Request !805 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/805 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:40:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:40:28 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: It didn't pass the CI because of the failing openssl compat test. To save CI credits I cancelled the last pipeline. I'm going to rebase it now and I'll let you know when you can review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117277089 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:44:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:44:12 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: I'll check it today -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117278468 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:50:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:50:48 +0000 Subject: [gnutls-devel] GnuTLS | updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on tests/tls13/anti_replay.c: > ret = gnutls_anti_replay_init(&anti_replay); > assert(ret == 0); > gnutls_anti_replay_set_window(anti_replay, 10000); > + gnutls_anti_replay_set_add_function(anti_replay, storage_add); > + gnutls_anti_replay_set_ptr(anti_replay, &storage); > gnutls_init(&session, GNUTLS_SERVER); I guess you could remove session related stuff completely as it's unused. Otherwise looks good to me. Thank you for doing that! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805#note_117280830 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 16:53:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 15:53:00 +0000 Subject: [gnutls-devel] GnuTLS | updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Merge Request !805 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/805 Branches: tmp-anti-replay-updates to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 18:42:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 17:42:53 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: @nmav I am keeping the build pipelines warm... In which Fedora build should we enable the tpmtool tests? I suppose we would need to run something like `dnf -y install tcsd tpm-tool swtpm` in one of them. FYI: The test case needs root rights due to tcsd wanting to run either as user tss or root and switching to tss. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117311321 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 14 22:46:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 21:46:37 +0000 Subject: [gnutls-devel] GnuTLS | tests: improve testsuite and ECC related minor fixes (!799) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/privkey_raw.c: > * gnutls_privkey_export_ecc_raw: > * @key: Holds the public key > * @curve: will hold the curve > - * @x: will hold the x coordinate > - * @y: will hold the y coordinate > + * @x: will hold the x-coordinate > + * @y: will hold the y-coordinate TBD: update docs for `gnutls_x509_privkey_export_ecc_raw`, `gnutls_x509_crt_get_pk_ecc_raw`, `gnutls_x509_crt_get_pk_gost_raw`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_117353469 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 00:19:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 23:19:42 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected certificate type! (%d)\n", gnutls_certificate_type_get(session)); I think this error message can be clearer. Is the `(%d)` giving the expected or the negotiated one? This is not clear from the text. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117364721 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 00:19:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 14 Nov 2018 23:19:43 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ Can you explain to me how this is solving the problem? As I recall correctly we decided to put the negotiated certificate types outside the if block to make sure that (under all TLS versions) newly negotiated values are ignored and the original (firstly) negotiated ones are used on resumed sessions. Where is this certificate type get bug coming from? If you don't explicitly negotiate cert types then the defaults (X.509) apply. The certificate type get functions should always return these defaults. Can you give me an example when it goes wrong? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117364720 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 01:03:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 00:03:40 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav it's ready for review. I'm planning to rename the lib/rawpk.c file to lib/cert-cred-rawpk.c after you approve everything. I haven't renamed it yet because git wouldn't recognize it anymore and you couldn't see incremental changes easily. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117368537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 08:30:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 07:30:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: All tests in ci run as root. In gnutls/build-images project we can install any additional packages we need to the f29 ci image. Swtpm should be already there -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117414829 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 10:17:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 09:17:46 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: I'm consulting with other parties. Will update this MR in a few hours/days. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117450946 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 10:50:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 09:50:03 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) References: Message-ID: New Merge Request !808 https://gitlab.com/gnutls/gnutls/merge_requests/808 Branches: tmp-autogen-bak-update to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This is an update of !801, cherry-picking the changes from !645. ## Checklist * [ ] 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/808 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:10:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:10:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected certificate type! (%d)\n", gnutls_certificate_type_get(session)); done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117466130 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:17:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:17:07 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ Thanks for that, I remembered we had discussed it but had lost the details. It seems that we didn't have a test for certificate types and resumption it and it never worked. Now when resuming under TLS1.3 the certificate type is changed from the default X509 to zero. That is, while the copy from resumed parameters to active session is done, the negotiated parameters are not stored in the resumed parameters when packing; and this copy that I replaced was actually setting a certificate type of zero. This made applications like lftp when using gnutls 3.6.4 to fail due to an unexpected certificate type when checking it on a resumed session. That's why I'm reverting that change and ensure that we test the expected behavior in terms of certificate type. Given that the intended use never worked, we should correctly fix it on the rfc7250, and also add a test which guarrantees that certificate types are correctly seen when resuming a session. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117467884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:20:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:20:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +int gnutls_certificate_set_raw_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_raw_pubkey_t SubjectPublicKeyInfo, > + const gnutls_x509_privkey_t key); > + > +int gnutls_certificate_get_raw_keypair(gnutls_certificate_credentials_t cred, > + unsigned index, //TODO check need for this one. do we want multiple keys? No TODOs please on final code; they are never followed up :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117468873 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:20:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:20:42 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/rawpubkey.c: > + > +#include > + > +/** TODO Same here about todos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117468934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:21:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:21:34 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/rawpubkey.c: > + /* TODO find out wat it does. now copied from x509 func. */ > + if( cred->pin.cb ) > + { > + gnutls_privkey_set_pin_function( privkey, cred->pin.cb, cred->pin.data ); > + } > + > + /* Import x509 private key into our generic private key struct */ > + ret = gnutls_privkey_import_x509( privkey, key, GNUTLS_PRIVKEY_IMPORT_COPY ); > + if( ret < 0 ) > + { > + gnutls_assert(); > + return ret; > + } > + > + /* We now convert our raw public key to a parsed certificate (pcert) structure */ > + // Allocate some memory nit: I think such comment is not necessary. The call to calloc is sufficient to indicate memory allocation is going on. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117469234 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:26:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:26:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Are 74 commits really needed for that feature? I do not think I can realistically go through them up before the release. Can they be combined in bigger self contained chunks 5-6 commits? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117470557 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:36:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:36:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/rawpubkey.c: > + /* TODO find out wat it does. now copied from x509 func. */ > + if( cred->pin.cb ) > + { > + gnutls_privkey_set_pin_function( privkey, cred->pin.cb, cred->pin.data ); > + } > + > + /* Import x509 private key into our generic private key struct */ > + ret = gnutls_privkey_import_x509( privkey, key, GNUTLS_PRIVKEY_IMPORT_COPY ); > + if( ret < 0 ) > + { > + gnutls_assert(); > + return ret; > + } > + > + /* We now convert our raw public key to a parsed certificate (pcert) structure */ > + // Allocate some memory You are looking at old code. Rawpubkey.c does not exist anymore. It should not be in the git tree. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117473406 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:37:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:37:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: As I commented before, I will merge all commits into one after you approve the MR. I just pushed my dev branch to speed up things so that I don't have to flatten everything after an update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117473786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 11:54:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 10:54:43 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ I understand. If I look at the packing code `session_pack.c` lines 913/914 I see that the cert types are only packed under TLS <1.3. Is this the desired behaviour or should we actually pack these params? Or should these values be renegotiated under TLS 1.3? Is that the reason why you moved the `dst->client_ctype = src->client_ctype;` to within the if-block? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117478672 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 12:49:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 11:49:00 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I'd like to review what the final view of the "story" is; the comments in the commit are part of the review, i.e., they guide what to review, and what to expect in the code that one is seeing. Flattening it all would still need a very good description on what is everything about, and from a quick glimpse it doesn't make much sense as auto-generated changes and unrelated changes will be bundled in a whole. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117501525 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 12:50:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 11:50:04 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: The pipelines are again all passing but the tpmtools_test.sh is being SKIP'ed and I think it's due to tpm_createek missing, which is in the tpm-tools package. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117501709 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 12:54:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 11:54:49 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ > I understand. If I look at the packing code `session_pack.c` lines 913/914 I see that the cert types are only packed under TLS <1.3. Is this the desired behaviour or should we actually pack these params? It is also my understanding is that this will be sufficient, though I had no easy way to test it is functional. > Or should these values be renegotiated under TLS 1.3? Is that the reason why you moved the `dst->client_ctype = src->client_ctype;` to within the if-block? Indeed now, I enabled re-negotiating them; keeping that behavior though it will mean that on a resumed version which is PSK, if one asks for the original certificate of the session (which is possible), he may see a different certificate type depending on the subsequent negotiation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117502907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 12:56:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 11:56:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ > > I understand. If I look at the packing code `session_pack.c` lines 913/914 I see that the cert types are only packed under TLS <1.3. Is this the desired behaviour or should we actually pack these params? > It is also my understanding is that this will be sufficient, though I had no easy way to test it is functional. Seeing however the tests I added, most likely they are sufficient as a basic functional test for X509. What do you think? Should I attempt fix it as part of the commit and the more elaborate tests with cert type changes are tested as part of the rfc7250 patches? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117503780 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 13:06:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 12:06:37 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: I've updated the F29 image to include tpm-tools. It will be available in CI once this pipeline completes: https://gitlab.com/gnutls/build-images/-/jobs/120944296 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117507808 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 13:43:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 12:43:52 +0000 Subject: [gnutls-devel] GnuTLS | tests: improve testsuite and ECC related minor fixes (!799) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/privkey_raw.c: > * gnutls_privkey_export_ecc_raw: > * @key: Holds the public key > * @curve: will hold the curve > - * @x: will hold the x coordinate > - * @y: will hold the y coordinate > + * @x: will hold the x-coordinate > + * @y: will hold the y-coordinate Thanks. Updated them as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799#note_117527593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 13:44:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 12:44:42 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: So what do you propose that I should do then? The whole MR is about adding raw public-key support. For the cert type negotiation you wanted 1 single commit. That's why I assumed that would be the case this time too. I can make a diff with the master and provide you with a single functional commit. What do you prefer? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117527784 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 13:46:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 12:46:06 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/rawpubkey.c: > + /* TODO find out wat it does. now copied from x509 func. */ > + if( cred->pin.cb ) > + { > + gnutls_privkey_set_pin_function( privkey, cred->pin.cb, cred->pin.data ); > + } > + > + /* Import x509 private key into our generic private key struct */ > + ret = gnutls_privkey_import_x509( privkey, key, GNUTLS_PRIVKEY_IMPORT_COPY ); > + if( ret < 0 ) > + { > + gnutls_assert(); > + return ret; > + } > + > + /* We now convert our raw public key to a parsed certificate (pcert) structure */ > + // Allocate some memory You are looking at old code. rawpubkey.c does not exist anymore. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117528071 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 13:46:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 12:46:27 +0000 Subject: [gnutls-devel] GnuTLS | updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: All discussions on Merge Request !805 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/805 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 14:43:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 13:43:34 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Now it's `nc` that is missing - nmap-ncat package. I hope it's not an issue. I moved away from using bash's /dev/tcp. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117543456 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 15:35:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 14:35:14 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Added. Running in https://gitlab.com/gnutls/build-images/pipelines/36735391 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117567259 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 15:37:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 14:37:06 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: If that's the case, then provide a single commit. But please do not mix in unrelated changes and auto-generated files as it would only delay things. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117567754 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 15:38:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 14:38:06 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: @stefanberger It would be awesome if you could list the needed tools / packages in README.md. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117568065 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 15:42:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 14:42:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I think a good rule about a merge request is to have some large cohesive commits with good description on the final stage. They do not need to be necessarily one commit. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117569328 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 16:01:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 15:01:33 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ Latest commit does that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_117575892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 16:19:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 15:19:31 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: @rockdaboot The new push is awesome :-) Have a look at the links. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117582854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 16:39:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 15:39:10 +0000 Subject: [gnutls-devel] GnuTLS | tests: improve testsuite and ECC related minor fixes (!799) In-Reply-To: References: Message-ID: All discussions on Merge Request !799 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/799 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 16:54:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 15:54:38 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) References: Message-ID: New Merge Request !809 https://gitlab.com/gnutls/gnutls/merge_requests/809 Project:Branches: rockdaboot/gnutls:tmp-tarball-build to gnutls/gnutls:master Author: Tim R?hsen Assignee: Tim R?hsen Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Finally found a stable yaml rule to use artifacts between stages (cache: doesn't work stable). So here comes a build from tarball without the need of a fully configured development system. The CI image, an Alpine 3.8 minimal system, is already in build-images (MR is created when this code is finished). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:08:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:08:18 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: @stefan Would it be better to have links to the 'homepage' instead of to the tree directory (e.g. https://sourceforge.net/p/trousers/tpm-tools/ci/master/tree/) ? That way someone gets a better overview and source hosting provider / link changes won't need an update in GnuTLS's README.md. I mean, that might be more 'stable'. WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117600654 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:21:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:21:34 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I'll see how I can rearrange my commits and let you know when I've pushed them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117604110 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:25:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:25:47 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: The homepage of TrouSerS and tpm-tools would be this one here: http://trousers.sourceforge.net/ Looks quite old, but I can replace it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117605227 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:29:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:29:21 +0000 Subject: [gnutls-devel] GnuTLS | tests: improve testsuite and ECC related minor fixes (!799) In-Reply-To: References: Message-ID: Merge Request !799 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/799 Branches: tmp-cert-status to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:29:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:29:25 +0000 Subject: [gnutls-devel] GnuTLS | tests: improve testsuite and ECC related minor fixes (!799) In-Reply-To: References: Message-ID: Merge Request !799 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/799 Branches: tmp-cert-status to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:33:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:33:48 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: @rockdaboot, could you take a look? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_117607961 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:43:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:43:04 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on src/Makefile.am: > - cp -p $${srcdir}$${b}.c.bak $${b}.c; \ > - cp -p $${srcdir}$${b}.h.bak $${b}.h; \ > - } && \ > - touch $@ > - > -.c.c.bak: > +args-std.def: args-std.def.in > $(AM_V_GEN) srcdir=''; \ > - test -f ./$@ || srcdir=$(srcdir)/; \ > - test -f $${srcdir}/$@ || cp -p $< $@ > + test -f ./$@.in || srcdir=$(srcdir)/; \ > + sed \ > + -e 's|@VERSION[@]|$(VERSION)|g' \ > + -e 's|@YEAR[@]|$(YEAR)|g' \ > + -e 's|@PACKAGE_BUGREPORT[@]|$(PACKAGE_BUGREPORT)|g' \ > + $${srcdir}$@.in > $@.tmp && mv $@.tmp $@ I need to do this. Configure script can handle generating the file. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_117610312 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:46:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:46:21 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on src/Makefile.am: > - cp -p $${srcdir}$${b}.c.bak $${b}.c; \ > - cp -p $${srcdir}$${b}.h.bak $${b}.h; \ > - } && \ > - touch $@ > - > -.c.c.bak: > +args-std.def: args-std.def.in > $(AM_V_GEN) srcdir=''; \ > - test -f ./$@ || srcdir=$(srcdir)/; \ > - test -f $${srcdir}/$@ || cp -p $< $@ > + test -f ./$@.in || srcdir=$(srcdir)/; \ > + sed \ > + -e 's|@VERSION[@]|$(VERSION)|g' \ > + -e 's|@YEAR[@]|$(YEAR)|g' \ > + -e 's|@PACKAGE_BUGREPORT[@]|$(PACKAGE_BUGREPORT)|g' \ > + $${srcdir}$@.in > $@.tmp && mv $@.tmp $@ Yes, the reason why I moved this back to `make` phase is that, `*.stamp` files (now included in the tarball) depend on args-std.def. If it was generated by configure, its timestamp would be always newer than `*.stamp` and thus autogen-regeneration would be triggered. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_117610971 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 17:47:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 16:47:01 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on src/Makefile.am: > - cp -p $${srcdir}$${b}.c.bak $${b}.c; \ > - cp -p $${srcdir}$${b}.h.bak $${b}.h; \ > - } && \ > - touch $@ > - > -.c.c.bak: > +args-std.def: args-std.def.in > $(AM_V_GEN) srcdir=''; \ > - test -f ./$@ || srcdir=$(srcdir)/; \ > - test -f $${srcdir}/$@ || cp -p $< $@ > + test -f ./$@.in || srcdir=$(srcdir)/; \ > + sed \ > + -e 's|@VERSION[@]|$(VERSION)|g' \ > + -e 's|@YEAR[@]|$(YEAR)|g' \ > + -e 's|@PACKAGE_BUGREPORT[@]|$(PACKAGE_BUGREPORT)|g' \ > + $${srcdir}$@.in > $@.tmp && mv $@.tmp $@ I see... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_117611123 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 19:28:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 18:28:12 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nice. A second stage looks like a good idea in general as we can bring also the build of applications using gnutls with a good test suite. I had tried that in the past with !477 but problems in gitlab prevented it from working. Maybe now we are close to that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_117632140 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 21:19:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 20:19:38 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: This won't currently build because `autogen` is missing. Wasn't the latest std-arg related commit(s) tested without installed `autogen` ? @dueno WDYT ? I also see in `src/`: ``` Package p11-kit-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `p11-kit-1.pc' to the PKG_CONFIG_PATH environment variable Package 'p11-kit-1', required by 'virtual:world', not found cat: can't open '/p11-kit/pkcs11.h': No such file or directory ``` Do we need a `if ENABLE_PKCS11` around p11tool ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_117648508 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 15 21:33:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 15 Nov 2018 20:33:57 +0000 Subject: [gnutls-devel] GnuTLS | tests/scripts/common.sh uses non-portable `date +%N` (#619) References: Message-ID: New Issue was created. Issue 619: https://gitlab.com/gnutls/gnutls/issues/619 Author: Tim R?hsen Assignee: Looks like the Alpine CI image doesn't like `date +%N` (nanoseconds). It returns an empty string. Alpine uses busybox. Any idea how to circumvent this resp. make it more portable ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/619 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 01:43:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 00:43:28 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: All discussions on Merge Request !802 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/802 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 01:43:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 00:43:27 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/x509/privkey_pkcs8.c: > case GNUTLS_PK_GOST_01: > case GNUTLS_PK_GOST_12_256: > case GNUTLS_PK_GOST_12_512: > - if ((ret = asn1_create_element Dropped this commit for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117679585 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 01:44:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 00:44:12 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: I have updated MR, dropped patch that changed generated private keys and added NEWS file entry. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802#note_117679634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 01:59:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 00:59:17 +0000 Subject: [gnutls-devel] GnuTLS | Add support for signed PKCS#12 (#620) References: Message-ID: New Issue was created. Issue 620: https://gitlab.com/gnutls/gnutls/issues/620 Author: Dmitry Eremin-Solenikov Assignee: Add support for PKCS#12 files with `authSafe` being of type `signedData`.[sample2.pfx](/uploads/b5352baccc8b976930da33027fe4fae6/sample2.pfx) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/620 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 03:15:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 02:15:37 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: minimal.F29 is now failing and I don't see log output. Is the `which` tool installed there? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117686491 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 06:37:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 05:37:11 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: > Wasn't the latest std-arg related commit(s) tested without installed autogen ? Yes, it is. I can successfully compile the tarball from [doc-dist.Fedora](https://gitlab.com/rockdaboot/gnutls/-/jobs/121185411) on [alpine-3.5.2 build-ready VM](http://www.nongnu.org/pretest/downloads/) after installing necessary packages (nettle-dev, libtasn1-dev, libunistring-dev) from the "edge" repository, though I see weird warnings as below: ``` ./configure --disable-doc --disable-guile --without-p11-kit ... GEN systemkey-args.stamp /home/miles/gnutls-3.6.4/build-aux/missing: line 81: autogen: not found WARNING: 'autogen' is missing on your system. ... CC systemkey.o CC systemkey-args.lo systemkey-args.c:42: warning: macro "OPTION_CODE_COMPILE" is not used [-Wunused-macros] #define OPTION_CODE_COMPILE 1 CCLD libcmd-systemkey.la copying selected object files to avoid basename conflicts... ar: `u' modifier ignored since `D' is the default (see `U') CCLD systemkey ... ``` These should be fixed once !808 is merged -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_117707089 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:02:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:02:29 +0000 Subject: [gnutls-devel] GnuTLS | test 0rtt replays on TLS sessions (#610) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #610: https://gitlab.com/gnutls/gnutls/issues/610 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:02:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:02:29 +0000 Subject: [gnutls-devel] GnuTLS | test 0rtt replays on TLS sessions (#610) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #610: https://gitlab.com/gnutls/gnutls/issues/610 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:02:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:02:29 +0000 Subject: [gnutls-devel] GnuTLS | test 0rtt replays on TLS sessions (#610) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #610: https://gitlab.com/gnutls/gnutls/issues/610 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:02:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:02:30 +0000 Subject: [gnutls-devel] GnuTLS | updates in anti-replay subsystem (!805) In-Reply-To: References: Message-ID: Merge Request !805 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/805 Branches: tmp-anti-replay-updates to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:02:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:02:30 +0000 Subject: [gnutls-devel] GnuTLS | test 0rtt replays on TLS sessions (#610) In-Reply-To: References: Message-ID: Reassigned Issue 610 https://gitlab.com/gnutls/gnutls/issues/610 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:04:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:04:31 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Merge Request !802 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/802 Project:Branches: GostCrypt/gnutls:gost-raw-privkeys to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:04:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:04:40 +0000 Subject: [gnutls-devel] GnuTLS | Improve support of GOST private keys parsing (!802) In-Reply-To: References: Message-ID: Merge Request !802 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/802 Project:Branches: GostCrypt/gnutls:gost-raw-privkeys to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:09:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:09:54 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: It seems we do not keep to .log files on the minimal build. You can copy the artifacts lines from another build to it to enable that (on .gitlab-ci.yml). A wild guess is that tpmtool is non functional or non-existing on that build. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117729124 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 09:14:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 08:14:02 +0000 Subject: [gnutls-devel] GnuTLS | tests/scripts/common.sh uses non-portable `date +%N` (#619) In-Reply-To: References: Message-ID: We'd need a better way to get a random number from that shell. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/619#note_117729934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 10:21:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 09:21:16 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) References: Message-ID: New Merge Request !810 https://gitlab.com/gnutls/gnutls/merge_requests/810 Project:Branches: GostCrypt/gnutls:pem-notext to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality tests * [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/810 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 10:26:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 09:26:39 +0000 Subject: [gnutls-devel] GnuTLS | tests/scripts/common.sh uses non-portable `date +%N` (#619) In-Reply-To: References: Message-ID: Reassigned Issue 619 https://gitlab.com/gnutls/gnutls/issues/619 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/619 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 11:37:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 10:37:04 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) In-Reply-To: References: Message-ID: Rebasing this to master and applying the following patch, makes eddsa work under PKCS#11. ``` diff --git a/tests/pkcs11/tls-neg-pkcs11-key.c b/tests/pkcs11/tls-neg-pkcs11-key.c index c32dee27a..0b69ae7ed 100644 --- a/tests/pkcs11/tls-neg-pkcs11-key.c +++ b/tests/pkcs11/tls-neg-pkcs11-key.c @@ -292,13 +292,12 @@ static const test_st tests[] = { .exp_kx = GNUTLS_KX_ECDHE_RSA, .exp_serv_err = GNUTLS_E_NO_CIPHER_SUITES }, - {.name = "tls1.2: ed25519 cert, ed25519 key", /* we cannot import that key */ + {.name = "tls1.2: ed25519 cert, ed25519 key", .pk = GNUTLS_PK_EDDSA_ED25519, .prio = "NORMAL:+ECDHE-RSA:+ECDHE-ECDSA", .cert = &server_ca3_eddsa_cert, .key = &server_ca3_eddsa_key, - .exp_kx = GNUTLS_KX_ECDHE_RSA, - .exp_key_err = GNUTLS_E_INVALID_REQUEST + .exp_kx = GNUTLS_KX_ECDHE_RSA } }; ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790#note_117770504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 12:00:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 11:00:22 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) In-Reply-To: References: Message-ID: LGTM. I'll merge it once https://gitlab.com/gnutls/gnutls/pipelines/36844647 succeeds. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790#note_117778222 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 12:13:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 11:13:22 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Hi @smuellerDD, Any updates on this MR? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_117782355 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 13:21:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 12:21:41 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: @dueno True, tarball compiles on the Alpine image despite those warnings :-) There are still tests failing due to non portable assumptions (Alpine is using busybox + musl). I am slowly going through them... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_117798683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 15:08:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 14:08:10 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Alright, it looks like it finally won this epic battle! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117828154 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 16:26:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 15:26:13 +0000 Subject: [gnutls-devel] GnuTLS | Fix max_early_data_size handling (!811) References: Message-ID: New Merge Request !811 https://gitlab.com/gnutls/gnutls/merge_requests/811 Branches: tmp-fix-max-early-data-size to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Looking at the coverage report, I realized that `gnutls_record_{get,set}_max_early_data_size()` is not tested. This adds a test and fixes the uncovered issue (the client ignored max_early_data_size advertised in NST). ## Checklist * [ ] 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/811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 17:55:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 16:55:02 +0000 Subject: [gnutls-devel] GnuTLS | add API to get access to early exporter (#329) In-Reply-To: References: Message-ID: Reassigned Issue 329 https://gitlab.com/gnutls/gnutls/issues/329 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/329 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:06:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:06:58 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) References: Message-ID: New Merge Request !812 https://gitlab.com/gnutls/gnutls/merge_requests/812 Branches: tmp-eddsa-pkcs11 to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This introduces support for Ed25519 under PKCS#11. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:07:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:07:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) In-Reply-To: References: Message-ID: Merge Request !790 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/790 Project:Branches: simo5/gnutls:eddsa_pkcs11 to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:07:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:07:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) In-Reply-To: References: Message-ID: It seems few more things are necessary for full ed25519 support. Replaced by !812. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790#note_117919584 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:12:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:12:13 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Merge Request !807 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/807 Project:Branches: stefanberger/gnutls:tpm12_testing to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:12:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:12:19 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Merge Request !807 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/807 Project:Branches: stefanberger/gnutls:tpm12_testing to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:12:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:12:20 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Reassigned Merge Request 807 https://gitlab.com/gnutls/gnutls/merge_requests/807 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 16 21:12:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 16 Nov 2018 20:12:58 +0000 Subject: [gnutls-devel] GnuTLS | tests: tpm: Add a test case for tpmtool (!807) In-Reply-To: References: Message-ID: Thank you! You have a addressed a long time technical debt! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/807#note_117920204 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 01:30:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 00:30:45 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav I've rearranged my commits. This should be the final version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_117956016 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 15:35:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 14:35:43 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > It seems the user friendliness of the (default) client certificate authentication was not prioritized in the TLS working group. They focused on the post-handshake authentication instead which provides a more natural way for it. Could glib-networking rely on that for tls1.3? All our tests still pass if using `GNUTLS_AUTO_REAUTH`, but the tests don't notice any difference in behavior. I'm actually not sure how it's relevant to this issue? Is there any reason an application would *not* want to use `GNUTLS_AUTO_REAUTH`? It seems like the sort of flag that everybody would want to use? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117993830 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 15:52:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 14:52:38 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > All our tests still pass if using `GNUTLS_AUTO_REAUTH`, but the tests don't notice any difference in behavior. I'm actually not sure how it's relevant to this issue? Ah well sorry, that's because I don't have the server side configured to call `gnutls_reauth()`. I guess your suggestion is that if I do that, then I can get a better error code from the client when reauth fails. Let me try. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117995307 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 15:52:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 14:52:48 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) References: Message-ID: New Issue was created. Issue 621: https://gitlab.com/gnutls/gnutls/issues/621 Author: Jaap Buurman Assignee: ## Description of problem: I am using Wine from WineHQ's official repository to run World of Warcraft. I use the Twitch client to keep my addons updated. On my desktop PC that is running Arch with GnuTLS 3.5.19 this is working fine. However, on my Laptop running Ubuntu 18.10 (Fresh install) it is unable to find and sync my addons. When I start the Twitch client from the terminal, the log is being spammed with the following messages: GnuTLS error: A packet with illegal or unsupported version was received. Said errors are missing when I do the same to run Twitch on my Arch Desktop PC. Is there a way to make the logging more verbose so I can provide more details regarding this issue? The contents of said packet would probably be a good starting point for chasing down the issue. ## Version of gnutls used: 3.6.4 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * Create a fresh Wine prefix via the "winecfg" command * Install dotnet 4.0 by running "winetricks dotnet40" * Change back the Windows version to "Windows 7" by running "winecfg" again. * Download & Install the Twitch app: https://app.twitch.tv/download * After installing, run the Twitch app again (By starting it from the terminal for logging purposes) and Switch to the Addon view. Enable/restart the app when asked. ## Actual results: Log is being spammed by the above mentioned error messages and is unable to Sync World of Warcraft addons. ## Expected results: There should be no GnuTLS errors and the application should properly sync and update the addons. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 16:32:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 15:32:41 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: >From your documentation of GNUTLS_AUTO_REAUTH: """This must be enabled with GNUTLS_POST_HANDSHAKE_AUTH for TLS1.3, and it requires to restore interrupted calls to gnutls_record_recv() based on the output of gnutls_record_get_direction() , i.e., gnutls_record_recv() could also be interrupted when sending when this flag is enabled.""" So if `gnutls_record_recv()` is interrupted and `gnutls_record_get_direction()` returns 1 (trying to write data) I have to next call `gnutls_record_send()` instead of restoring the call to `gnutls_record_recv()`? Not sure that's easier. (Also we can't use `gnutls_record_get_direction()` because we do unfortunately support reading and writing simultaneously on separate threads.) Seems much easier to handle reauth manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117997619 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 16:35:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 15:35:40 +0000 Subject: [gnutls-devel] build-images | New Alpine CI runner (!12) References: Message-ID: New Merge Request !12 https://gitlab.com/gnutls/build-images/merge_requests/12 Branches: tmp-alpine to master Author: Tim R?hsen Assignee: This works locally to build gnutls from tarball - please merge so I can continue the MR testing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/12 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 16:35:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 15:35:48 +0000 Subject: [gnutls-devel] build-images | New Alpine CI runner (!12) In-Reply-To: References: Message-ID: Merge Request !12 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/12 Branches: tmp-alpine to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/12 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 16:58:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 15:58:30 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: When a function is interrupted the same function has to be restored. What the documentation is sating is that you may need to restore recv even when sending is unblocked -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117999571 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:00:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:00:20 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: The manual method gives you more control on when, how and if to do reauth. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_117999717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:12:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:12:46 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Maybe we have a documentation issue here.... > When a function is interrupted the same function has to be restored. What the documentation is sating is that you may need to restore recv even when sending is unblocked I don't understand at all. If `gnutls_record_recv()` is interrupted, then the documentation says I have to call `gnutls_record_get_direction()`. (Which we cannot do in glib-networking, but let's pretend.) Then what am I supposed to do with the result of `gnutls_record_get_direction()` before calling `gnutls_record_recv()` again? If `gnutls_record_recv()` will pick up sending and handle everything transparently, then why is `gnutls_record_get_direction()` mentioned in the documentation at all? Obviously I already know that if `gnutls_record_recv()` is interrupted I have to call it again, but the documentation for `GNUTLS_AUTO_REAUTH` has me thinking that's no longer the case and special handling is required. (It would probably be good to also document that `GNUTLS_AUTO_REAUTH` must not be used if the application is sending and receiving data on two threads at once.) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_118000589 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:38:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:38:28 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: > I don't understand at all. If `gnutls_record_recv()` is interrupted, then the documentation says I have to call `gnutls_record_get_direction()`. (Which we cannot do in glib-networking, but let's pretend.) Then what am I supposed to do with the result of `gnutls_record_get_direction()` before calling `gnutls_record_recv()` again? That's to assist in selecting the flags for poll or select, or whichever way you'll figure that the channel is open for the direction it is expected. That is, indeed you'll call it again, but it tries to say when that should be. Nice catch about the threaded case. Would you like to propose an update on that text? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_118002292 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:44:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:44:04 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: Thank you for reporting that. gnutls 3.6.4 introduces TLS1.3, and it could be that the server the application is connecting is choking with it. I'd suggest to try using gnutls from the master branch, and if that fails as well, could you use wireshark to see the communication that fails and attach it here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118002633 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:44:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:44:43 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 17:46:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 16:46:06 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Would it make sense to test whether some of the prominent options of certtool work as expected with this flag? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_118002762 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:01:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:01:50 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Aaaah that makes sense now. For GNUTLS_AUTO_REAUTH: Enable transparent re-authentication in client side when the server requests to. That is, reauthentication is handled within gnutls_record_recv(), and the %GNUTLS_E_REHANDSHAKE or %GNUTLS_E_REAUTH_REQUEST are not returned. This must be enabled with %GNUTLS_POST_HANDSHAKE_AUTH for TLS1.3, and it requires to restore interrupted calls to gnutls_record_recv() based on the output of gnutls_record_get_direction() since gnutls_record_recv() could be interrupted when sending when this flag is enabled. Note this flag may not be used if you are using the same session for sending and receiving in different threads. For gnutls_record_get_direction(): This function provides information about the internals of the record protocol and is only useful if a prior gnutls function call, e.g. gnutls_handshake(), was interrupted for some reason. That is, if a function returned GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN. In such a case, you might want to call select() or poll() before restoring the interrupted gnutls function. This function is useful to determine whether the function was interrupted while sending or receiving, so that select() or poll() may be called appropriately. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_118007104 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:31:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:31:09 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ I took another look at the spec and found this quote: > In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each handshake even when in resumption-PSK mode. However, 0-RTT parameters are those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see Section 4.2.10). Following that your solution adheres to the spec and makes sure that the certificate type negotiation extensions are also renegotiated under TLS 1.3. Indeed we may end up in a situation where there is a certificate type mismatch between the newly negotiated type and the previously exchanged certificate. The question is, is this a problem? Should we deviate from the spec and pack the cert type params or should we accept mismatches? In the former case, should we propose a modification of the spec perhaps for this edge case? What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118008625 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:32:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:32:05 +0000 Subject: [gnutls-devel] GnuTLS | With TLS 1.3 enabled, gnutls_handshake() succeeds in client when client fails to send required certificate (#615) In-Reply-To: References: Message-ID: Thank you. I've clarified the text based on that suggestion. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/615#note_118008685 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:34:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:34:33 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: btw. you can enable debugging of gnutls setting the environment variables `GNUTLS_DEBUG_LEVEL=6`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118008798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:42:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:42:27 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: @nmav In the Alpine image, `tests/slow/test-ciphers-api.sh` fails with ``` trying aes128-gcm trying aes256-gcm trying aes128-cbc trying aes256-cbc trying 3des-cbc Assertion failed: !(length % block_size) (cbc.c: nettle_cbc_encrypt: 53) _check_wait_status:153: Child died with signal 11 default cipher tests failed FAIL test-ciphers-api.sh (exit status: 1) ``` Any idea ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118009348 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:45:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:45:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected X509 certificate type! (%d)\n", gnutls_certificate_type_get(session)); > + > if (counter == 0 && gnutls_certificate_get_ours(session) == NULL) > fail("no certificate returned on server side (%s)\n", counter?"resumed session":"first session"); Just a minor detail when looking at this code. Maybe put spaces around the ops in the second param of fail()? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118009620 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:53:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:53:58 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ > Following that your first solution adheres to the spec and makes sure that the certificate type negotiation extensions are also renegotiated under TLS 1.3. Indeed we may end up in a situation where there is a certificate type mismatch between the newly negotiated type and the previously exchanged certificate. The question is, is this a problem? Let's take an example. If we keep the strict RFC behavior, that if we adopt the behavior above, it means that in a resumed session `gnutls_certificate_type_get()` may return `raw` while `gnutls_certificate_get_peers` will return an X.509 certificate. How would you see that behavior as an potential user of these functions? It looks quite dangerous to me, especially if one cert can be read both ways (e.g., a specially crafted one - probably impossible in that example). > In the former case, should we propose a modification of the spec perhaps for this edge case? What do you think? The only problematic case would be a situation where a protocol requires negotiation with X.509 certificates, while it allows resuming a session with a different certificate type for use in post-handshake authentication. Not sure how possible is that scenario, and it looks like a harmless limitation but maybe, we can even handle it the following way: if the resumed session negotiates a different certificate than the original one, then all the authentication info data (i.e., certificates from the original session) are cleared up. That way the application will see any empty certificate, and could use the new certificate type in a potential post-handshake auth. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118010022 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 19:58:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 18:58:23 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: Thank you very much for your response! I will try to compile and test the master branch tomorrow. For now here's a debugging log that hopefully shows something useful: ` gnutls[5]: REC[0x7d200fa0]: Allocating epoch #0 gnutls[2]: added 4 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list gnutls[5]: REC[0x7d200fa0]: Allocating epoch #1 gnutls[4]: HSK[0x7d200fa0]: Adv. version: 3.3 gnutls[2]: Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384) gnutls[2]: Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256) gnutls[2]: Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256) gnutls[2]: Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256) gnutls[2]: Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384) gnutls[2]: Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305) gnutls[2]: Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM) gnutls[2]: Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1) gnutls[2]: Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256) gnutls[2]: Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM) gnutls[2]: Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1) gnutls[2]: Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384) gnutls[2]: Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305) gnutls[2]: Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1) gnutls[2]: Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256) gnutls[2]: Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1) gnutls[2]: Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384) gnutls[2]: Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM) gnutls[2]: Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) gnutls[2]: Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256) gnutls[2]: Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM) gnutls[2]: Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1) gnutls[2]: Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384) gnutls[2]: Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305) gnutls[2]: Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM) gnutls[2]: Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) gnutls[2]: Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256) gnutls[2]: Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM) gnutls[2]: Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Maximum Record Size/1) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (OCSP Status Request/5) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension OCSP Status Request/5 (5 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Client Certificate Type/19) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Server Certificate Type/20) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Supported Groups/10) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sent group SECP256R1 (0x17) gnutls[4]: EXT[0x7d200fa0]: Sent group SECP384R1 (0x18) gnutls[4]: EXT[0x7d200fa0]: Sent group SECP521R1 (0x19) gnutls[4]: EXT[0x7d200fa0]: Sent group X25519 (0x1d) gnutls[4]: EXT[0x7d200fa0]: Sent group FFDHE2048 (0x100) gnutls[4]: EXT[0x7d200fa0]: Sent group FFDHE3072 (0x101) gnutls[4]: EXT[0x7d200fa0]: Sent group FFDHE4096 (0x102) gnutls[4]: EXT[0x7d200fa0]: Sent group FFDHE6144 (0x103) gnutls[4]: EXT[0x7d200fa0]: Sent group FFDHE8192 (0x104) gnutls[4]: EXT[0x7d200fa0]: Sending extension Supported Groups/10 (20 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Supported EC Point Formats/11) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Supported EC Point Formats/11 (2 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (SRP/12) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Signature Algorithms/13) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: sent signature algo (4.1) RSA-SHA256 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.9) RSA-PSS-SHA256 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.4) RSA-PSS-RSAE-SHA256 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (4.3) ECDSA-SHA256 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.7) EdDSA-Ed25519 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (5.1) RSA-SHA384 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.10) RSA-PSS-SHA384 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.5) RSA-PSS-RSAE-SHA384 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (5.3) ECDSA-SHA384 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (6.1) RSA-SHA512 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.11) RSA-PSS-SHA512 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (8.6) RSA-PSS-RSAE-SHA512 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (6.3) ECDSA-SHA512 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (2.1) RSA-SHA1 gnutls[4]: EXT[0x7d200fa0]: sent signature algo (2.3) ECDSA-SHA1 gnutls[4]: EXT[0x7d200fa0]: Sending extension Signature Algorithms/13 (32 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (SRTP/14) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Heartbeat/15) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (ALPN/16) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Encrypt-then-MAC/22) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Encrypt-then-MAC/22 (0 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Extended Master Secret/23) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Extended Master Secret/23 (0 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Session Ticket/35) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Session Ticket/35 (0 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Key Share/51) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: sending key share for SECP256R1 gnutls[4]: EXT[0x7d200fa0]: sending key share for X25519 gnutls[4]: EXT[0x7d200fa0]: Sending extension Key Share/51 (107 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Supported Versions/43) for 'client hello' gnutls[2]: Advertizing version 3.4 gnutls[2]: Advertizing version 3.1 gnutls[4]: EXT[0x7d200fa0]: Sending extension Supported Versions/43 (5 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Post Handshake Auth/49) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Safe Renegotiation/65281) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Safe Renegotiation/65281 (1 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Server Name Indication/0) for 'client hello' gnutls[2]: HSK[0x7d200fa0]: sent server name: 'addons-ecs.forgesvc.net' gnutls[4]: EXT[0x7d200fa0]: Sending extension Server Name Indication/0 (28 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Cookie/44) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Early Data/42) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (PSK Key Exchange Modes/45) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension PSK Key Exchange Modes/45 (3 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Record Size Limit/28) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Sending extension Record Size Limit/28 (2 bytes) gnutls[4]: EXT[0x7d200fa0]: Preparing extension (ClientHello Padding/21) for 'client hello' gnutls[4]: EXT[0x7d200fa0]: Preparing extension (Pre Shared Key/41) for 'client hello' gnutls[4]: HSK[0x7d200fa0]: CLIENT HELLO was queued [360 bytes] gnutls[5]: REC[0x7d200fa0]: Preparing Packet Handshake(22) with length: 360 and min pad: 0 gnutls[5]: REC[0x7d200fa0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 365 gnutls[3]: ASSERT: ../../lib/buffers.c[get_last_packet]:1171 gnutls[3]: ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 gnutls[3]: ASSERT: ../../lib/buffers.c[get_last_packet]:1171 gnutls[5]: REC[0x7d200fa0]: SSL 3.3 Handshake packet received. Epoch 0, length: 69 gnutls[5]: REC[0x7d200fa0]: Expected Packet Handshake(22) gnutls[5]: REC[0x7d200fa0]: Received Packet Handshake(22) with length: 69 gnutls[5]: REC[0x7d200fa0]: Decrypted Packet[0] Handshake(22) with length: 69 gnutls[4]: HSK[0x7d200fa0]: SERVER HELLO (2) was received. Length 65[65], frag offset 0, frag length: 65, sequence: 0 gnutls[3]: ASSERT: ../../lib/buffers.c[get_last_packet]:1162 gnutls[3]: ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1413 gnutls[4]: HSK[0x7d200fa0]: Server's version: 3.3 gnutls[3]: ASSERT: ../../lib/handshake.c[read_server_hello]:1835 gnutls[3]: ASSERT: ../../lib/handshake.c[_gnutls_recv_handshake]:1514 gnutls[3]: ASSERT: ../../lib/handshake.c[handshake_client]:2853 GnuTLS error: A packet with illegal or unsupported version was received. gnutls[5]: REC[0x7d200fa0]: Start of epoch cleanup gnutls[5]: REC[0x7d200fa0]: End of epoch cleanup gnutls[5]: REC[0x7d200fa0]: Epoch #0 freed gnutls[5]: REC[0x7d200fa0]: Epoch #1 freed ` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118010298 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 20:11:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 19:11:31 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: I suspect something is wrong in the application or wine. The application seems to advertise TLS1.3 and TLS1.0, and that confuses the server who selects TLS1.2. ``` gnutls[2]: Advertizing version 3.4 gnutls[2]: Advertizing version 3.1 ``` My high level understanding of the wine code is that it allows an application to specifically remove some versions of TLS and keep some others, however it is not ready for TLS1.3 being available. That's the reason the application you use ends up advertising TLS1.3 and TLS1.0, although probably the intention was to only have TLS1.0 there. Seeing wine's `schan_imp_create_session` it did not anticipate a new protocol being added to the list. I suggest opening an issue at the wine issue tracker. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118010887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 20:12:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 19:12:29 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: I think they need to either add support for TLS1.3 if schannel has it, or remove all enabled versions using `-VERS-ALL` before adding one explicitly selected by the application. It is a long guess though, as I do not claim to fully comprehend the code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118010926 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 20:31:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 19:31:07 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ A cert type / cert mismatch can indeed lead to parsing / interpretation problems and should therefore be avoided I think. Therefore I think that the solution to pack the originally negotiated params is our best option. >if the resumed session negotiates a different certificate than the original one, then all the authentication info data (i.e., certificates from the original session) are cleared up. That way the application will see any empty certificate, and could use the new certificate type in a potential post-handshake auth. Indeed I don't know whether that is a scenario that will be used but if we want to allow it I think this would be a good solution yes. That means that we have to build some extra checks in the cert type negotiation extensions. One important question is now whether this is an unforeseen use case in the spec and whether the spec should be updated to ensure consistent behavior between different implementations? How bad is it so deviate from the spec to prevent the possibility to end up in an unwanted scenario? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118013331 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 17 23:23:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 17 Nov 2018 22:23:11 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Why does GNUTLS_PIN=${PASS} not work (for certtool) on the cross runners, but on all other runners ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118022681 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 19:53:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 18:53:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ > One important question is now whether this is an unforeseen use case in the spec and whether the spec should be updated to ensure consistent behavior between different implementations? > How bad is it so deviate from the spec to prevent the possibility to end up in an unwanted scenario? The immediate or short term concern is none. Note also that this is not about the spec, but about the behavior of our API/ABI. The spec allows a very large set of options, but our API is always more restricted (we don't support all possible TLS extensions, nor all possible X.509 extensions either). It is about documenting it, and possibly creating an issue to track it if we believe that use case is something to worry about (most likely you know more on whether this use case makes sense). Anyway let's separate the future handling of the certificate types from this fix. I believe that this fix should be part of 3.6.5 to address the known regressions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118094988 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 19:57:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 18:57:11 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected X509 certificate type! (%d)\n", gnutls_certificate_type_get(session)); > + > if (counter == 0 && gnutls_certificate_get_ours(session) == NULL) > fail("no certificate returned on server side (%s)\n", counter?"resumed session":"first session"); Why do you think that? I do not think that this is part of the [Linux kernel coding style/rules](https://www.kernel.org/doc/html/v4.10/process/coding-style.html). In particular it explicitly asks not to do that: ``` Do not add spaces around (inside) parenthesized expressions. This example is bad: s = sizeof( struct file ); ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118095262 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 20:03:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 19:03:05 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_PIN_FINAL_TRY: This is the final try before blocking. > * @GNUTLS_PIN_COUNT_LOW: Few tries remain before token blocks. > * @GNUTLS_PIN_WRONG: Last given PIN was not correct. > + * @GNUTLS_PIN_MAY_BE_MISSING: It is fine if the PIN is missing. Ok, so if I understand correctly, an existing application using the callback and ignores this flag is unaffected. Would you like to write that info as part of the `GNUTLS_PIN_MAY_BE_MISSING` documentation above? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_118095617 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 20:08:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 19:08:31 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Is that something we should include in 3.6.5? ([it will be released at the 30th of November](https://gitlab.com/gnutls/gnutls/milestones/17)), or it can wait? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_118095872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 20:09:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 19:09:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Ok, thank you. I'll try to review it for inclusion in 3.6.5. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118095947 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 20:10:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 19:10:04 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Reassigned Merge Request 650 https://gitlab.com/gnutls/gnutls/merge_requests/650 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 20:23:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 19:23:51 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ I've updated the documentation of these functions to clarify their behavior under resumption. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118096816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:02:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:02:53 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: Thank you for that. I like in that board that we can have a view restricted to 3.6.x bugfixes and the ones selected for the milestone in question. I miss the burnout chart that there is in the milestones view :( Nevertheless, we could work with something like that, though the "Open" and "Closed" lists are quite unmanageable due to many items being there. In practice the workflow that I had in mind was using two views: 1. To select items to move from the various backlogs to the currently open releases 2. To view what items remain, and what to pick from the plan for the next release but it is quite influenced from my work in a team with strict goals and deliverables. In practice the gnutls workflow is (or my impression of it is): 1. There are various backlogs around. One is the large set of bugs that affect or may potentially affect someone, some are project based (e.g., the tls1.3 backlog). These, at least for the ones we know, we group using the "milestones" option. 2. A new milestone is made for each release; some bugs which are important for the next release are proposed for it 3. Whatever fix is introduced before the release date is included as long as it follows the contribution guide (e.g., tests) unless vetoed (with 'after next release' label) 4. At release date, any remaining bugs in the release milestone are moved to the backlog for the release series (3.6.x) That is, (2) and (4) are quite indicative of intentions rather than restrictive in any way, and could even be skipped as steps and still get to the same result (with possibly losing some transparency). Do you think that we can have a board (or two) which is helpful for (a) contributors, and (b) the developers working on gnutls? Somehow related. From reading the above, it seems that the milestone way of tracking projects is not a good one as one issue cannot be both in the tls1.3 and the 3.6.5 release milestone. Or even better in 'tls1.3' and 'gnutls 3.6.x bugfixes' and '3.6.5 release'. Most likely labels will serve better in tracking such features/projects. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_118099361 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:17:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:17:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom commented on a discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected X509 certificate type! (%d)\n", gnutls_certificate_type_get(session)); > + > if (counter == 0 && gnutls_certificate_get_ours(session) == NULL) > fail("no certificate returned on server side (%s)\n", counter?"resumed session":"first session"); I was talking about this part: `counter?"resumed session":"first`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118100304 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:22:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:22:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default Typo: `...side to sent to the peer` -> `...side to send to the peer`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118100571 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:23:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:23:15 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default > + * X.509, unless an alternative certificate type is enabled by > + * gnutls_init() and negotiated in the session. Would you say "in" the session or "for" the session? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118100643 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:25:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:25:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default > + * X.509, unless an alternative certificate type is enabled by > + * gnutls_init() and negotiated in the session. > + * > + * Resumed sessions will return the certificate type that was negotiated > + * and used in the original session. > * > * As of version 3.6.4 it is recommended to use > - * gnutls_certificate_type_get2(). > + * gnutls_certificate_type_get2() which is more fine grained. Fine grained is officially spelled with a hyphen: fine-grained. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118100799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 18 21:30:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 18 Nov 2018 20:30:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/constate.c: > dst->prf = src->prf; \ > dst->grp = src->grp; \ > dst->pversion = src->pversion; \ > + dst->client_ctype = src->client_ctype; \ Looks good. I've given some minor spelling comments for the updated docs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118101077 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 06:54:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 05:54:15 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/resume.c: > #if defined(USE_X509) > unsigned int l; > > + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) > + fail("did not find the expected X509 certificate type! (%d)\n", gnutls_certificate_type_get(session)); > + > if (counter == 0 && gnutls_certificate_get_ours(session) == NULL) > fail("no certificate returned on server side (%s)\n", counter?"resumed session":"first session"); Ok, this was not modified as part of this patch. I've submitted a separate patch for this cleanup, though I think it may be good to restrict the scope of this fix, and not extend it further to a cleanup patch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118139779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 06:54:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 05:54:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default > + * X.509, unless an alternative certificate type is enabled by > + * gnutls_init() and negotiated in the session. Thanks, indeed sounds strange. I used "during the session" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118139816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 06:54:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 05:54:46 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default > + * X.509, unless an alternative certificate type is enabled by > + * gnutls_init() and negotiated in the session. > + * > + * Resumed sessions will return the certificate type that was negotiated > + * and used in the original session. > * > * As of version 3.6.4 it is recommended to use > - * gnutls_certificate_type_get2(). > + * gnutls_certificate_type_get2() which is more fine grained. done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118139824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 06:55:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 05:55:04 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/state.c: > * gnutls_certificate_type_get: > * @session: is a #gnutls_session_t type. > * > - * The certificate type is by default X.509, unless it is negotiated > - * as a TLS extension. > + * This function returns the type of the certificate that is negotiated > + * for this side to sent to the peer. The certificate type is by default Nice catch. Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118139852 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 07:05:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 06:05:44 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: I haven't seen the comments, but I guess making the test suite work with busybox will be quite a challenge. Not sure how important is that to go for it. Is there a particular reason to run our testsuite on alpine? Why not use debian or centos? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118140860 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 09:48:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 08:48:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Because Alpine is different with it's busybox + musl backend. It is a very clean/lean distribution widely used as base for docker / VM images. The fixed incompatibilities in the test suite may be blockers on other OSes as well, so fixing extends the possible GnuTLS distributions. And the above mentioned assertion may easily be a bug in libgnutls (didn't look at it closer , though). Also we are pretty close, all is fixed except the error in `tests/slow/test-ciphers-api.sh`. A question regarding `\r` (Carriage Return) handling: In some tests with `diff`, the CR is ignored (I guess it's for Windows compatibility) and in others not. Does anyone *sometimes* build+test GnuTLS on Windows ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118166356 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 11:35:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 10:35:46 +0000 Subject: [gnutls-devel] GnuTLS | READ -1 returned from 0x8, errno=104 gerrno=0 (#622) References: Message-ID: New Issue was created. Issue 622: https://gitlab.com/gnutls/gnutls/issues/622 Author: Theodor Reppe Assignee: ## Description of problem: I am trying to use syslog with TLS. When setting everything up, I get unexpected GnuTLS error -54 in nsd_gtls.c:1738: Error in the pull function. ## Version of gnutls used: 3.4.10-4ubuntu1.4 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## more error log 3286.452009070:main Q:Reg/w0 : GnuTLS log msg, level 4: EXT[0x7f62cc02b7c0]: sent signature algo (2.3) ECDSA-SHA1 3286.452030600:main Q:Reg/w0 : GnuTLS log msg, level 4: EXT[0x7f62cc02b7c0]: Sending extension SIGNATURE ALGORITHMS (22 bytes) 3286.452054633:main Q:Reg/w0 : GnuTLS log msg, level 4: HSK[0x7f62cc02b7c0]: CLIENT HELLO was queued [227 bytes] 3286.452089017:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: Preparing Packet Handshake(22) with length: 227 and min pad: 0 3286.452112547:main Q:Reg/w0 : GnuTLS log msg, level 9: ENC[0x7f62cc02b7c0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 3286.452139655:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 232 3286.452202901:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_buffers.c:1154 3286.463138148:main Q:Reg/w0 : GnuTLS log msg, level 10: READ: -1 returned from 0x8, errno=104 gerrno=0 3286.463187809:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_buffers.c:367 3286.463201844:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_buffers.c:588 3286.463226029:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_record.c:1038 3286.463246030:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_record.c:1158 3286.463265525:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_buffers.c:1409 3286.463286203:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_handshake.c:1446 3286.463306184:main Q:Reg/w0 : GnuTLS log msg, level 3: ASSERT: gnutls_handshake.c:2762 3286.463330709:main Q:Reg/w0 : Called LogMsg, msg: unexpected GnuTLS error -54 in nsd_gtls.c:1738: Error in the pull function. 3286.463358730:main Q:Reg/w0 : main Q: qqueueAdd: entry added, size now log 7, phys 8 entries 3286.463378620:main Q:Reg/w0 : main Q: EnqueueMsg advised worker start 3286.463417051:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: Start of epoch cleanup 3286.463446464:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: End of epoch cleanup 3286.463474647:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: Epoch #0 freed 3286.463495235:main Q:Reg/w0 : GnuTLS log msg, level 5: REC[0x7f62cc02b7c0]: Epoch #1 freed 3286.463515950:main Q:Reg/w0 : TCPSendInit FAILED with -2078. 3286.463572072:main Q:Reg/w0 : file netstrms.c released module 'lmnsd_gtls', reference count now 0 3286.463593867:main Q:Reg/w0 : module 'lmnsd_gtls' has zero reference count, unloading... If you need more information / logs, please let me know. Thank you in advance for your effort on this! Theodor -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/622 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 12:44:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 11:44:55 +0000 Subject: [gnutls-devel] GnuTLS | Fix max_early_data_size handling (!811) In-Reply-To: References: Message-ID: Merge Request !811 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/811 Branches: tmp-fix-max-early-data-size to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 12:44:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 11:44:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix max_early_data_size handling (!811) In-Reply-To: References: Message-ID: Merge Request !811 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/811 Branches: tmp-fix-max-early-data-size to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 12:45:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 11:45:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix max_early_data_size handling (!811) In-Reply-To: References: Message-ID: LGTM! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/811#note_118228340 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 12:45:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 11:45:30 +0000 Subject: [gnutls-devel] GnuTLS | add support for Ed25519 (eddsa) over PKCS#11 (#417) In-Reply-To: References: Message-ID: Reassigned Issue 417 https://gitlab.com/gnutls/gnutls/issues/417 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:36:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:36:11 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: Issue with 4.5 was fixed by !803, Issue with 4.6 is 'WONTFIX', so I'm closing this for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612#note_118240899 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:36:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:36:17 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #612: https://gitlab.com/gnutls/gnutls/issues/612 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:36:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:36:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Merge Request !806 was approved by Tom Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/806 Branches: tmp-fix-certificate-type to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:47:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:47:05 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: I will look into extending existing tests. BTW: do you think that text-less mode will also make sense for `--p7-info`/`--p8-info`/`--p12-info`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_118243834 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:55:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:55:35 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: All discussions on Merge Request !806 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/806 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:55:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:55:42 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) In-Reply-To: References: Message-ID: Merge Request !806 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/806 Branches: tmp-fix-certificate-type to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 13:55:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 12:55:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806) 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/806#note_118246199 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 14:19:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 13:19:11 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Increase tests of RSA functionality (!813) References: Message-ID: New Merge Request !813 https://gitlab.com/gnutls/gnutls/merge_requests/813 Branches: tmp-rsa-tests to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This merge request set adds RSA-PSS testing and functional testing of RSA decryption API under gnutls_privkey_import_ext4(). This builds on top of !812 ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/813 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 14:21:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 13:21:28 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Increase tests of RSA functionality (!813) In-Reply-To: References: Message-ID: @lumag commit 4bdaad1f3db6f4e716a2bddd32765c7081caa6c1 also corrects the testing of `GNUTLS_PK_GOST_12_512`. It would be nice if you can verify that this is the intended behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/813#note_118264806 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 14:28:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 13:28:34 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: My would be that one may specify that for converting from DER to PEM of these structures. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_118274066 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:19:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:19:36 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/test-ciphers-api.sh (cipher-api-test.c) relies on undefined behavior (#623) References: Message-ID: New Issue was created. Issue 623: https://gitlab.com/gnutls/gnutls/issues/623 Author: Tim R?hsen Assignee: I tracked down the failure of this test on Alpine (busybox+musl)... as is turns out the test relies on a special glibc behavior of abort(). Which is even the opposite of the documented behavior :-). One way to achieve a stable behavior would be to split the test into several smaller ones and avoiding `signal(SIGABRT, ...)`. The man page of Debian (libc 2.27) says ``` If the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by restoring the default disposition for SIGABRT and then raising the signal for a second time. ``` But the test does the opposite by setting a signal handler for SIGABRT, assuming that the process doesn't abort in this case, e.g. ``` signal(SIGABRT, custom_abrt); ret = gnutls_cipher_add_auth(ch, data, 16); signal(SIGABRT, SIG_DFL); if (ret >= 0 && error_detected == 0) fail("succeeded in adding auth data data after partial data were given\n"); ``` This seems to work with glibc 2.27 but can change with any new version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:36:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:36:15 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_PIN_FINAL_TRY: This is the final try before blocking. > * @GNUTLS_PIN_COUNT_LOW: Few tries remain before token blocks. > * @GNUTLS_PIN_WRONG: Last given PIN was not correct. > + * @GNUTLS_PIN_MAY_BE_MISSING: It is fine if the PIN is missing. Not quite. I introduced this flag to prevent the existing PIN callback from exiting (`exit(1)`), which was ok before when the first attempt was made to use the srk_password = NULL, which could then fail if the TPM 1.2 had a real password. I turned this around now, asking the PIN callback first, which may not not have a PIN, which is fine, and we try the srk_password = NULL then instead. ``` if (password[0] == 0 || password[0] == '\n') { if (flags & GNUTLS_PIN_MAY_BE_MISSING) return -1; fprintf(stderr, "No PIN given.\n"); if (info != NULL && info->batch != 0) { fprintf(stderr, "note: when operating in batch mode, set the GNUTLS_PIN or GNUTLS_SO_PIN environment variables\n") } exit(1); } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_118304979 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:42:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:42:46 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on tests/tls-neg-ext4-key.c: > gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, > s_xcred); > > - gnutls_priority_set_direct(server, > - "NORMAL:+VERS-SSL3.0:+ANON-ECDH:+ANON-DH:+ECDHE-RSA:+DHE-RSA:+RSA:+ECDHE-ECDSA:+CURVE-X25519:+SIGN-EDDSA-ED25519", > - NULL); > + assert(gnutls_priority_set_direct(server, > + "NORMAL", > + NULL)>=0); nit: can this be a single line? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118306955 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:42:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:42:47 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on tests/pkcs11/pkcs11-eddsa-privkey-test.c: > +/* > + * Copyright (C) 2017 Red Hat, Inc. 2018 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118306950 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:42:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:42:47 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on tests/pkcs11/pkcs11-eddsa-privkey-test.c: > + gnutls_x509_crt_t crt; > + gnutls_x509_privkey_t key; > + gnutls_datum_t tmp, sig; > + gnutls_privkey_t pkey; > + gnutls_pubkey_t pubkey; > + gnutls_pubkey_t pubkey2; > + unsigned i, sigalgo; > + > + bin = softhsm_bin(); > + > + lib = softhsm_lib(); > + > + ret = global_init(); > + if (ret != 0) { > + fail("%d: %s\n", ret, gnutls_strerror(ret)); > + exit(1); nit: I would expect `fail()` calls exit by itself -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118306947 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:42:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:42:47 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/pkcs11_write.c: > break; > } > case GNUTLS_PK_EC: > + case GNUTLS_PK_EDDSA_ED25519: > { > gnutls_free(p.data); > gnutls_free(x.data); nit: `x` is not used for Ed25519 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118306952 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:43:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:43:38 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Looks good to me, except the nits. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118307187 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 15:43:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 14:43:51 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Merge Request !812 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/812 Branches: tmp-eddsa-pkcs11 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:06:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:06:35 +0000 Subject: [gnutls-devel] GnuTLS | crypto-self-tests-pk: added RSA-PSS sign/verify tests (4bdaad1f) In-Reply-To: References: Message-ID: Yes, this is correct from my point of view. Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/4bdaad1f3db6f4e716a2bddd32765c7081caa6c1#note_118315444 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:35:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:35:47 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/test-ciphers-api.sh (cipher-api-test.c) relies on undefined behavior of abort() (#623) In-Reply-To: References: Message-ID: Reassigned Issue 623 https://gitlab.com/gnutls/gnutls/issues/623 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:43:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:43:18 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Created an issue (#623) and just pushed a possible fix to this MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118327577 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:53:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:53:06 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/pkcs11/pkcs11-eddsa-privkey-test.c: > + gnutls_x509_crt_t crt; > + gnutls_x509_privkey_t key; > + gnutls_datum_t tmp, sig; > + gnutls_privkey_t pkey; > + gnutls_pubkey_t pubkey; > + gnutls_pubkey_t pubkey2; > + unsigned i, sigalgo; > + > + bin = softhsm_bin(); > + > + lib = softhsm_lib(); > + > + ret = global_init(); > + if (ret != 0) { > + fail("%d: %s\n", ret, gnutls_strerror(ret)); > + exit(1); Thanks, nice catch. There were few fprintfs as well; replaced them with fail(). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118330623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:53:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:53:58 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/tls-neg-ext4-key.c: > gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, > s_xcred); > > - gnutls_priority_set_direct(server, > - "NORMAL:+VERS-SSL3.0:+ANON-ECDH:+ANON-DH:+ECDHE-RSA:+DHE-RSA:+RSA:+ECDHE-ECDSA:+CURVE-X25519:+SIGN-EDDSA-ED25519", > - NULL); > + assert(gnutls_priority_set_direct(server, > + "NORMAL", > + NULL)>=0); Looks better indeed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118331117 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:54:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:54:10 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/pkcs11/pkcs11-eddsa-privkey-test.c: > +/* > + * Copyright (C) 2017 Red Hat, Inc. Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118331230 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:55:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:55:29 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/pkcs11_write.c: > break; > } > case GNUTLS_PK_EC: > + case GNUTLS_PK_EDDSA_ED25519: > { > gnutls_free(p.data); > gnutls_free(x.data); since `x` is initialized to zero, it looks simpler to have it like this rather than adding a special case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812#note_118331790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:55:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:55:29 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: All discussions on Merge Request !812 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/812 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 16:55:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 15:55:48 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) 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/812#note_118331893 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 18:04:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 17:04:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) References: Message-ID: New Merge Request !814 https://gitlab.com/gnutls/gnutls/merge_requests/814 Project:Branches: stefanberger/gnutls:tpm12_extend_testcase to gnutls/gnutls:master Author: Stefan Berger Assignee: Fix some minor issues in the TPM test cases where the dash does not seem to understand `&>/dev/null` and it's better to try to terminate a process with SIGTERM first and then try to kill it with SIGKILL. We may need this for an extension to the test cases. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 18:11:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 17:11:13 +0000 Subject: [gnutls-devel] GnuTLS | add support for Ed25519 (eddsa) over PKCS#11 (#417) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #417: https://gitlab.com/gnutls/gnutls/issues/417 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 18:11:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 17:11:17 +0000 Subject: [gnutls-devel] GnuTLS | Added support for Ed25519 keys under PKCS#11 (!812) In-Reply-To: References: Message-ID: Merge Request !812 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/812 Branches: tmp-eddsa-pkcs11 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 19 22:35:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 19 Nov 2018 21:35:28 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: `--p*-info` do not output original structures. I have the feeling that it might be good to restructure `certtool-common.c`. Functions doing the similar things have diffrent prototypes, etc. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_118442320 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 10:32:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 09:32:29 +0000 Subject: [gnutls-devel] GnuTLS | Increase tests of RSA functionality (!813) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/813 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 10:34:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 09:34:56 +0000 Subject: [gnutls-devel] GnuTLS | Increase tests of RSA functionality (!813) In-Reply-To: References: Message-ID: @Vrancken not all commits have the signed-off-by flag. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/813#note_118645134 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 10:35:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 09:35:36 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @Vrancken not all commits have the signed-off-by flag. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118645372 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 11:14:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 10:14:25 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Sorry that must have been gone wrong during the rebasing. I've fixed it and pushed the repaired commits. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118657747 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 11:33:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 10:33:47 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) References: Message-ID: New Merge Request !815 https://gitlab.com/gnutls/gnutls/merge_requests/815 Branches: tmp-tls10-tls13-fix to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list It can happen that an application due to a misconfiguration, enables TLS1.3 in combination with TLS1.0 or TLS1.1 only. In that case a server which is unaware of the TLS1.3 protocol will reply by selecting the TLS1.2 protocol instead and that answer will be rejected by the client. With this change we ensure that TLS1.3 is not enabled in these problematic scenarios. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/815 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 11:36:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 10:36:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/publickey.c: > */ > static const gnutls_pk_map pk_mappings[] = { > {GNUTLS_KX_RSA, GNUTLS_PK_RSA, CIPHER_ENCRYPT}, > - {GNUTLS_KX_DHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > - {GNUTLS_KX_SRP_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > - {GNUTLS_KX_ECDHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > + {GNUTLS_KX_DHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, // DHE KX signed with RSA The comments here seem unrelated as well. Not sure about their usefulness either. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118665128 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 11:38:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 10:38:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/algorithms/publickey.c: > */ > static const gnutls_pk_map pk_mappings[] = { > {GNUTLS_KX_RSA, GNUTLS_PK_RSA, CIPHER_ENCRYPT}, > - {GNUTLS_KX_DHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > - {GNUTLS_KX_SRP_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > - {GNUTLS_KX_ECDHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, > + {GNUTLS_KX_DHE_RSA, GNUTLS_PK_RSA, CIPHER_SIGN}, // DHE KX signed with RSA Hmm I thought I removed all those comments. I'll remove it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118665682 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 12:04:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 11:04:05 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I'm reviewing the code, but there are quite few questions in the code in the form of remarks. That doesn't seem to be like final code to be merged in 3.6.5. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118676963 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 12:27:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 11:27:02 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: All irrelevant TODOs and REMARKS are removed in subsequent commits. I've rebased everything in logical commit chunks but sometimes there are some TODOs or comments left that I couldn't remove without rewriting my entire code. If it's easier I can merge all commits so that you only see the end result? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118684672 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:41:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:41:29 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PCERT_NO_CERT is unused (#624) References: Message-ID: New Issue was created. Issue 624: https://gitlab.com/gnutls/gnutls/issues/624 Author: Nikos Mavrogiannopoulos Assignee: It seems that the flag `GNUTLS_PCERT_NO_CERT` is unused and is no longer used throughout the code. We should remove any references of it, and keep it while documenting as no-op in API. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/624 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:45:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:45:53 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I'm not able to comment in rawpk.c (something wrong with the gitlab interface). There seems to be a memleak in `gnutls_certificate_set_rawpk_key_mem`: ``` if ((ret = _gnutls_check_key_cert_match(cred)) < 0) { return gnutls_assert_val(ret); } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118712695 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:38 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/client_cert_type.c: > ssize_t len = data_size; > const uint8_t* pdata = data; > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) Why remove the check for explicit enabling on `gnutls_init`? Shouldn't it should check that rfc7250 keys are enabled? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714442 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > typedef enum CertificateSigType { RSA_SIGN = 1, DSA_SIGN = 2, ECDSA_SIGN = 64 > } CertificateSigType; > > -/* Moves data from a internal certificate struct (gnutls_pcert_st) to > +/* Moves data from an internal certificate struct (gnutls_pcert_st) to > * another internal certificate struct (cert_auth_info_t), and deinitializes > * the former. > */ > int _gnutls_pcert_to_auth_info(cert_auth_info_t info, gnutls_pcert_st * certs, size_t ncerts) > { > + /* REMARK: why do we free certs here? It is unexpected behavior and might be undesireable That looks like an item to discuss. It shouldn't be in the code if that's a final version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714444 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > +} > + > + > int > _gnutls_gen_cert_client_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.client_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the client > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); not sure if we need to call an external API instead of the accessing the parameter directly. What are the benefits from calling that function? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714454 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:50 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > return ret; > } > > - if (apr_cert_list_length > 0) { > + if (apr_cert_list_length > 0) { // REMARK: is this check complete? What if there is a cert set but no corresponding priv key? We can't sign then. How can this be the case? Do the rawpk APIs allow to set a public key without a private? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/x509.h: > #define BARE_PEM_OCSP_RESPONSE "OCSP RESPONSE" > > #define PEM_CRL_SEP "-----BEGIN X509 CRL" > +//REMARK: the defines above are also (more or less) defined in /lib/x509/common.h. Maybe combine in one place? makes sense to have a cleanup; though that comment should not be in the final code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714497 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > > } > > + > +/* Locates the first certificate that holds a raw public-key. nit: I think `Locates the first raw public-key` is more accurate. `certificate` would mean to me an X.509 certificate -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714450 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/session.c: > - } else { > - // print proto version, client cert type, server cert type > - snprintf(proto_name, sizeof(proto_name), "%s-%s-%s", > - gnutls_protocol_get_name(get_num_version(session)), > - gnutls_certificate_type_get_name(ctype_client), > - gnutls_certificate_type_get_name(ctype_server)); > - } > - } else { // Assumed default certificate type (X.509) > - snprintf(proto_name, sizeof(proto_name), "%s", > - gnutls_protocol_get_name(get_num_version > - (session))); > + // Get certificate types > + ctype_client = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > + ctype_server = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > + > + if (ctype_client == ctype_server) { This should be kept executing when no alternative cert types are enabled. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714474 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > struct gnutls_openpgp_keyring_int; > typedef struct gnutls_openpgp_keyring_int *gnutls_openpgp_keyring_t; > > +/* Raw public key types */ > +struct gnutls_rawpubkey_st; > +typedef struct gnutls_rawpubkey_st* gnutls_rawpubkey_t; On other cases RAWPK is used a short to raw public key while here rawpubkey is used. We should be consistent and use a single short version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714543 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > } > > - /* Correctly set the certificate type depending on whether we > - * have explicitly negotiated certificate types (RFC7250). > - */ > - if (_gnutls_has_negotiate_ctypes(session)) { > - if (IS_SERVER(session)) { > - type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > - } else { // Client mode > - type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > - } > - } else { > - type = DEFAULT_CERT_TYPE; > + /* Correctly set the certificate type */ > + if (IS_SERVER(session)) { > + type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); wouldn't it further simplify the code if doing a single call with CTYPE_OURS parameter? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714501 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + * Currently it only makes sense to associate one raw pubkey per session. > + * Associating more raw pubkeys with a session has no use because we > + * don't know how to select the correct one. > + */ > +static int > +find_rawpk_cert(gnutls_session_t session, > + const gnutls_certificate_credentials_t cred, > + const gnutls_pk_algorithm_t* pk_algos, > + int pk_algos_length, int* indx) > +{ > + unsigned i; > + gnutls_pk_algorithm_t pk; > + > + *indx = -1; > + > + // Traverse all certificate credentials nit: Given the for loop on the next line this comment seems unnecessary. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714455 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:45 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.h: > size_t _data_size, > gnutls_datum_t * vparams); > > +//TODO #ifdef ENABLE_RAWPK todo should not be in final code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714466 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > - find_x509_client_cert(session, cred, _data, _data_size, > - pk_algos, pk_algos_length, &indx); > - } else { > - result = GNUTLS_E_UNIMPLEMENTED_FEATURE; > + switch (cert_type) { > + case GNUTLS_CRT_X509: > + result = find_x509_client_cert(session, cred, _data, > + _data_size, pk_algos, > + pk_algos_length, &indx); > + break; > + case GNUTLS_CRT_RAWPK: > + result = find_rawpk_cert(session, cred, > + pk_algos, pk_algos_length, &indx); > + break; > + default: > + result = GNUTLS_E_UNIMPLEMENTED_FEATURE; //REMARK: what is the best err code here, the current one or GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE? The unsupported looks more suitable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714557 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > * certificate and then check its compatibility with > * the ciphersuites. > */ > - > - /* If the callback which retrieves the certificate has been set, why this comment was removed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714558 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + const gnutls_certificate_credentials_t cred, > + const gnutls_pk_algorithm_t* pk_algos, > + int pk_algos_length, int* indx) > +{ > + unsigned i; > + gnutls_pk_algorithm_t pk; > + > + *indx = -1; > + > + // Traverse all certificate credentials > + for (i = 0; i < cred->ncerts; i++) { > + /* We know that our list length will be 1, therefore we can > + * ignore the rest. > + */ > + if (cred->certs[i].cert_list_length == 1) { > + // If the *_SIGN algorithm and cert type match the cert is our cert! The comment here doesn't seem to match what is going on further. There is no check for signature algorithms. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/client_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > const version_entry_st* vers = get_version(session); > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) Same here. enabling it by default is a regression since the last version. This should only be parsed if the application explicitly enabled alternative types. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:53 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > switch (type) { > - case GNUTLS_CRT_X509: > - return gnutls_pcert_import_x509_raw(pcert, > - &info-> > - raw_certificate_list > - [0], > - GNUTLS_X509_FMT_DER, > - GNUTLS_PCERT_NO_CERT); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + case GNUTLS_CRT_X509: > + return gnutls_pcert_import_x509_raw(pcert, > + &info->raw_certificate_list[0], > + GNUTLS_X509_FMT_DER, > + GNUTLS_PCERT_NO_CERT); // REMARK: this last param is not used. Indeed its use seems to be have been phased out. I've opened #624 to handle it. The remark shouldn't be in the final code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714517 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > gnutls_datum_t tmp; > > cred = (gnutls_certificate_credentials_t) > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE); > + _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE); //REMARK: why check for credentials here? an application is required to set certificate credentials when doing certificate authentication. That enforces that rule. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714518 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/state.c: > // No explicit priorities set, and default ctype is asked > if (ctype_priorities->num_priorities == 0 > && cert_type == DEFAULT_CERT_TYPE) > - return 0; // ok > + return GNUTLS_E_SUCCESS; unrelated change; the convention in the library is to return `0`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714481 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > return GNUTLS_E_INSUFFICIENT_CREDENTIALS; > } > > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); Is there a particular reason to avoid using the `session->security_parameters.client_ctype`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714536 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > } > } > > int > _gnutls_gen_cert_server_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.server_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the server > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); nit: not sure about introducing a function call for all these uses. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714460 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > > } > > + > +int _gnutls_proc_rawpk_crt(gnutls_session_t session, > + uint8_t * data, size_t data_size) //REMARK: maybe place this in a different file specific for RawPK? > +{ > + int cert_size, ret; > + cert_auth_info_t info; > + gnutls_pcert_st* peer_certificate; > + gnutls_datum_t tmp_cert; > + > + uint8_t *p = data; // data pointer nit: is that comment necessary here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714499 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:47 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > > } > > + > +/* Locates the first certificate that holds a raw public-key. > + * Currently it only makes sense to associate one raw pubkey per session. > + * Associating more raw pubkeys with a session has no use because we > + * don't know how to select the correct one. > + */ > +static int > +find_rawpk_cert(gnutls_session_t session, Is that function only intended to be called by clients? If yes, I think its name should reflect it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714476 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed > + if (pubkey == NULL) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + // Reset our pcert memory to all zeros same here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714456 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/state.c: > // No explicit priorities set, and default ctype is asked > if (ctype_priorities->num_priorities == 0 > && cert_type == DEFAULT_CERT_TYPE) > - return 0; // ok > + return GNUTLS_E_SUCCESS; > > /* Now lets find out whether our cert type is in our priority > * list, i.e. set of allowed cert types. > */ > for (i = 0; i < ctype_priorities->num_priorities; i++) { > if (ctype_priorities->priorities[i] == cert_type) > - return 0; /* ok */ > + return GNUTLS_E_SUCCESS; same here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714484 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > /** > * gnutls_certificate_status_t: > * @GNUTLS_CERT_INVALID: The certificate is not signed by one of the > - * known authorities or the signature is invalid (deprecated by the flags > + * known authorities or the signature is invalid (deprecated by the flags > * %GNUTLS_CERT_SIGNATURE_FAILURE and %GNUTLS_CERT_SIGNER_NOT_FOUND). > * @GNUTLS_CERT_SIGNATURE_FAILURE: The signature verification failed. > * @GNUTLS_CERT_REVOKED: Certificate is revoked by its authority. In X.509 this will be > * set only if CRLs are checked. > - * @GNUTLS_CERT_SIGNER_NOT_FOUND: The certificate's issuer is not known. > + * @GNUTLS_CERT_SIGNER_NOT_FOUND: The certificate's issuer is not known. unrelated changes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714525 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > return data->length - init_pos; > } > > + > +/* Generates a Raw Public Key certificate message that holds only the > + * SubjectPublicKeyInfo part of a regular certificate message. > + * > + * Returns the number of bytes sent or a negative error code. > + */ > +int > +_gnutls_gen_rawpk_crt(gnutls_session_t session, gnutls_buffer_st* data) //REMARK: maybe place this in a different file specific for RawPK? May be cleaner. The remark shouldn't be in the final version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714472 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/server_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) Same here. Should not be parsed by default. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714469 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check nit: The comment here looks unnecessary. You added a detailed comment below. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:57 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > > /* Converts the first certificate for the cert_auth_info structure > * to a pcert. > + * > + * REMARK 1: why limit ourselves to only be able to convert the first cert in the chain? > + * REMARK 2: there is a lot of conversion between a raw cert / cert chain (gnutls_datum_t) > + * and gnutls_pcert_st going on (e.g. cert_auth_info to pcert). There is also quite some > + * overlap in data between these two types. The difference is that pcert holds only 1 cert > + * and cert_auth_info has the entire chain. During cert reception (in e.g. _gnutls_proc_x509_server_crt) > + * we also convert from raw to pcert. First we call gnutls_pcert_import_x509_raw to get a list with pcerts. > + * Then we call check_pk_compat to do some checks. Finally we call _gnutls_pcert_to_auth_info to save all That's a long remark. If you still would like to discuss it, please raise it on the merge request discussion section. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714561 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > GNUTLS_NO_AUTO_REKEY = (1<<15), > GNUTLS_SAFE_PADDING_CHECK = (1<<16), > GNUTLS_ENABLE_EARLY_START = (1<<17), > - GNUTLS_ENABLE_CERT_TYPE_NEG = (1<<18), > GNUTLS_AUTO_REAUTH = (1<<19), > - GNUTLS_ENABLE_EARLY_DATA = (1<<20) > + GNUTLS_ENABLE_EARLY_DATA = (1<<20), > + GNUTLS_ENABLE_RAWPK = (1<<21) This should replace `GNUTLS_ENABLE_CERT_TYPE_NEG` (use the same number), and should be documented. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714510 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth.c: > } > } > > -/* > +/* No changes other than space changes are done in that file. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714541 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:56 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on .gitignore: > *.trs > win32 > win64 > +*.orig That seems unrelated. Nevertheless, should we ignore it? I used 'git status' to show these so I clean them up. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714494 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed nit: I think the code below is very clear of what it is doing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + * where > + * length = 3 bytes and > + * certificate = length bytes. > + */ > + ret = _gnutls_buffer_append_data_prefix(data, 24, > + apr_cert_list[0].cert.data, > + apr_cert_list[0].cert.size); > + > + if (ret < 0) return gnutls_assert_val(ret); > + > + return data->length; > + } else { > + /* We found more than one certificate. In that case we don't know > + * which one to send, therefore we send nothing. > + */ > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); // TODO maybe introduce new error type GNUTLS_E_RAWPK_TOO_MANY_KEYS_GIVEN? I think it may be better to make that an impossible situation to happen during a handshake, i.e., check on input that the number of certificates given is the expected one. Introducing an error code would make sense if that's something to be triggered by reasonable code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714546 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:49 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/publickey.c: > .curve = GNUTLS_ECC_CURVE_INVALID }, > { .name = "EC/ECDSA", .oid = "1.2.840.10045.2.1", .id = GNUTLS_PK_ECDSA, > .curve = GNUTLS_ECC_CURVE_INVALID }, > - { .name = "EdDSA (Ed25519)", .oid = SIG_EDDSA_SHA512_OID, .id = GNUTLS_PK_EDDSA_ED25519, > + { .name = "EdDSA (Ed25519)", .oid = SIG_EDDSA_SHA512_OID, .id = GNUTLS_PK_EDDSA_ED25519, The following changes are unrelated as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714532 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check > + if (cred->certs[0].cert_list_length > 0 && The check for `certs[0].cert_list_length > 0` seems superfluous. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714445 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:50 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/x509.h: > */ > > #include > -#include why is this removed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714489 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > } > > + > +int _gnutls_proc_rawpk_crt(gnutls_session_t session, > + uint8_t * data, size_t data_size) //REMARK: maybe place this in a different file specific for RawPK? > +{ > + int cert_size, ret; > + cert_auth_info_t info; > + gnutls_pcert_st* peer_certificate; > + gnutls_datum_t tmp_cert; > + > + uint8_t *p = data; // data pointer > + ssize_t dsize = data_size; > + > + // Check whether we've received anything. > + if (data == NULL || data_size == 0) { I believe that the equivalent test on X.509 case is mainly for backwards compatibility as this message is invalid. Do you think we need that for raw public keys? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714475 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + int ret; > + gnutls_pcert_st *apr_cert_list; > + gnutls_privkey_t apr_pkey; > + int apr_cert_list_length; > + > + // Retrieve the appropriate certificate > + if((ret = _gnutls_get_selected_cert(session, &apr_cert_list, > + &apr_cert_list_length, &apr_pkey)) < 0) { > + return gnutls_assert_val(ret); > + } > + > + /* Since we are transmitting a raw public key with no additional > + * certificate credentials attached to it, it doesn't make sense to > + * have more than one certificate set (i.e. to have a certificate chain). > + */ > + if (apr_cert_list_length == 1) { nit: it would have been simpler to return the error immediately if the list does not equal one. Since you are testing for validity of the cert structure nevertheless, why don't you check that the certificate is of RAW type? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714459 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > > + > +/* Generates a Raw Public Key certificate message that holds only the > + * SubjectPublicKeyInfo part of a regular certificate message. > + * > + * Returns the number of bytes sent or a negative error code. > + */ > +int > +_gnutls_gen_rawpk_crt(gnutls_session_t session, gnutls_buffer_st* data) //REMARK: maybe place this in a different file specific for RawPK? > +{ > + int ret; > + gnutls_pcert_st *apr_cert_list; > + gnutls_privkey_t apr_pkey; > + int apr_cert_list_length; > + > + // Retrieve the appropriate certificate nit: the comment seems unnecessary; the next line seems quite expressive -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714479 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:53 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/cert_types.h: > switch (cert_type) { > case GNUTLS_CRT_X509: > return 0; > + case GNUTLS_CRT_RAWPK: > + return 2; > default: > return GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE; > } > } > + > +/* Checks whether the given cert type is enabled in the application > + */ > +static inline bool _gnutls_is_cert_type_enabled(gnutls_session_t session, gnutls_certificate_type_t cert_type) if it is static and inline why not remove the `_gnutls_` prefix? It will ease using/typing it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714515 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:45 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + * don't know how to select the correct one. > + */ > +static int > +find_rawpk_cert(gnutls_session_t session, > + const gnutls_certificate_credentials_t cred, > + const gnutls_pk_algorithm_t* pk_algos, > + int pk_algos_length, int* indx) > +{ > + unsigned i; > + gnutls_pk_algorithm_t pk; > + > + *indx = -1; > + > + // Traverse all certificate credentials > + for (i = 0; i < cred->ncerts; i++) { > + /* We know that our list length will be 1, therefore we can If we know that the list will be one why is it checked below? If you worry about static analyzers I think that's the definition of using an `assert()`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714461 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + * @format: The format of the raw public-key. DER or PEM. > + * @key_usage: An ORed sequence of %GNUTLS_KEY_* flags. > + * @flags: zero for now > + * > + * This convenience function will import (i.e. convert) the given raw > + * public key @rawpubkey into a #gnutls_pcert_st structure. The structure > + * must be deinitialized afterwards using gnutls_pcert_deinit(); > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 The version is wrong -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714468 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:53:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:53:00 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > /* Register a custom tls extension > */ > int gnutls_ext_register(const char *name, int type, gnutls_ext_parse_type_t parse_type, > - gnutls_ext_recv_func recv_func, gnutls_ext_send_func send_func, > + gnutls_ext_recv_func recv_func, gnutls_ext_send_func send_func, > gnutls_ext_deinit_data_func deinit_func, gnutls_ext_pack_func pack_func, > gnutls_ext_unpack_func unpack_func); > > int gnutls_session_ext_register(gnutls_session_t, const char *name, int type, gnutls_ext_parse_type_t parse_type, > - gnutls_ext_recv_func recv_func, gnutls_ext_send_func send_func, > + gnutls_ext_recv_func recv_func, gnutls_ext_send_func send_func, unrelated changes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714549 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:53 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert.h: > +/* wouldn't the `cert-cred.h` be more suitable as it will correspond to where these functions are implemented? It will also reduce any possible clashes with `auth/cert.h` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714523 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/server_cert_type.c: > ssize_t len = data_size; > const uint8_t* pdata = data; > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) Same here. Should not be parsed by default. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714463 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:52:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:52:56 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > /** > * gnutls_vdata_types_t: > * @GNUTLS_DT_UNKNOWN: Unknown data type. > - * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname; the hostname will be > + * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname; the hostname will be unrelated changes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118714527 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 13:58:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 12:58:02 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: > All irrelevant TODOs and REMARKS are removed in subsequent commits. I've rebased everything in logical commit chunks but sometimes there are some TODOs or comments left that I couldn't remove without rewriting my entire code. If it's easier I can merge all commits so that you only see the end result? I've provided a review of the first commit message. Given your comment above what would you prefer to do, would you like to discuss the suggestions, and after that merge the commits for another review? I think all but the last commit are very related and make sense to be merged (if possible please separate auto-generated changes). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118716104 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 14:02:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 13:02:05 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Thanks for that! Please spare yourself any further horrors. I'm going to merge all commits because you are sometimes reviewing stuff that is already fixed in the later commits. I couldn't rearrange it during rebasing. I think its best if you just look at the final result. I'll push it in a couple of minutes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118717184 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 14:12:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 13:12:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Okay, so this should be the pre-release verion. It contains only a few remarks that I would like you to answer. After that, I will fix these final issues (or at least remove the comments). Also, I will look at your previous comments to see whether I've missed something in my final version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118720364 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 15:47:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 14:47:15 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/test-ciphers-api.sh (cipher-api-test.c) relies on undefined behavior of abort() (#623) In-Reply-To: References: Message-ID: This test works with both linux and freebsd libc and I doubt they will ever change that handling. Making this test more portable is quite some work. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/623#note_118757753 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 15:48:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 14:48:34 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > Does anyone _sometimes_ build+test GnuTLS on Windows ? The CI itself builds and tests gnutls on windows (see the mingw builds). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118758179 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 15:52:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 14:52:04 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/certtool: > exit 1 > fi > > - #check whether ask-pass is being honoured > - ${SETSID} "${CERTTOOL}" --generate-self-signed --load-privkey ${TMPFILE1} --template "${srcdir}/templates/template-test.tmpl" --ask-pass >${TMPFILE2} 2>&1 <<<${PASS} > + #check whether password is being honoured The reason of this test is to test `--ask-pass`. I do not think we should be reducing coverage. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118759367 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 15:58:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 14:58:15 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > Because Alpine is different with it's busybox + musl backend. It is a very clean/lean distribution widely used as base for docker / VM images. The fixed incompatibilities in the test suite may be blockers on other OSes as well, so fixing extends the possible GnuTLS distributions. And the above mentioned assertion may easily be a bug in libgnutls (didn't look at it closer , though). I did a quick check of the changes and I'm not sure about them; indeed they increase portability of the testsuite, but is that the goal of the test suite? I see as the main goal of the test suite to test gnutls and apps as much as possible. Whether it works using `zsh`, `busybox` or any other restricted shell is not something we should care. We should make things easy for us and require tools like `bash` to allow us writing simple and easy test suites. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118761286 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 15:54:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 14:54:22 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pem-decoding: > fi > > #FIXME: the output string differs in windows and linux on the last char. > -${DIFF} -I 'Algorithm Security Level' "${srcdir}/data/bmpstring.pem" ${TMPFILE} || ${DIFF} -I 'Algorithm Security Level' --strip-trailing-cr "${srcdir}/data/bmpstring.pem" ${TMPFILE} > +${DIFF} "${srcdir}/data/bmpstring.pem" ${TMPFILE} This change would mean that every time we change the mapping of security level of parameters (e.g., when 1024 gets to weak), we will have to be modifying the test suite. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118760121 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 16:44:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 15:44:04 +0000 Subject: [gnutls-devel] GnuTLS | Increase tests of RSA functionality (!813) In-Reply-To: References: Message-ID: Merge Request !813 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/813 Branches: tmp-rsa-tests to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/813 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 16:44:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 15:44:04 +0000 Subject: [gnutls-devel] GnuTLS | Increase tests of RSA functionality (!813) In-Reply-To: References: Message-ID: Merged manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/813#note_118775240 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 17:04:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 16:04:14 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > The CI itself builds and tests gnutls on windows (see the mingw builds). MinGW + Wine is a pretty limited surrogate of Windows. E.g. I know that Wget+GnuTLS works on MinGW flawlessly, but it doesn't do at all on real Windows. Just an example. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118780803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 17:08:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 16:08:08 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/certtool: > exit 1 > fi > > - #check whether ask-pass is being honoured > - ${SETSID} "${CERTTOOL}" --generate-self-signed --load-privkey ${TMPFILE1} --template "${srcdir}/templates/template-test.tmpl" --ask-pass >${TMPFILE2} 2>&1 <<<${PASS} > + #check whether password is being honoured Right, but the underlying `getpass()` is not only LEGACY but also very special in what it takes as input stream. I will revert this and skip the test if bash is not available. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118781999 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 17:08:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 16:08:21 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/pem-decoding: > fi > > #FIXME: the output string differs in windows and linux on the last char. > -${DIFF} -I 'Algorithm Security Level' "${srcdir}/data/bmpstring.pem" ${TMPFILE} || ${DIFF} -I 'Algorithm Security Level' --strip-trailing-cr "${srcdir}/data/bmpstring.pem" ${TMPFILE} > +${DIFF} "${srcdir}/data/bmpstring.pem" ${TMPFILE} Right, will change this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118782065 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 17:13:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 16:13:42 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > Is portability the goal of our test suite? Clearly yes. Building GnuTLS on a platform is one thing. Another is the correct functionality on that platform. The typical, approved and widely used build+test sequence is `./configure && make && make check && sudo make install`. Would you really recommend to leave out `make check` ? > We should make things easy for us and require any tools necessary that allow us writing simple and easy test suites. Yes true. But the proposed changes are mostly trivial. For complicated stuff, we can simply depend on bash and skip that part if bash is not available. With that you can at least test the major functions/tools even if bash not installed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118783646 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 19:53:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 18:53:38 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: Reassigned Issue 621 https://gitlab.com/gnutls/gnutls/issues/621 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 20:01:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 19:01:50 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > > Is portability the goal of our test suite? > Clearly yes. Building GnuTLS on a platform is one thing. Another is the correct functionality on that platform. The typical, approved and widely used build+test sequence is `./configure && make && make check && sudo make install`. Would you really recommend to leave out `make check` ? No that was not what I suggested. make check will run everywhere though it may require bash to be available. I may be missing something, but I do not see it as an unreasonable requirement given the list of dependencies that we already have. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118843082 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 20:07:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 19:07:18 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Why I argue about this is because on several occasions I remember with the test suite using `bash` allowed to make a test on a reasonable amount of time and with reasonable amount of lines (and bash itself is not the easiest thing out there for a test suite). Forcing the use of posix subset for shells will indeed allow tests but make them harder to write, i.e., increase development time and make the option of not writing a test more attractive. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_118843924 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 20:10:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 19:10:02 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: We could actually prevent applications from setting such incorrect set of protocols. I've proposed a fix in !815. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118844397 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 21:47:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 20:47:21 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/client_cert_type.c: > ssize_t len = data_size; > const uint8_t* pdata = data; > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) We discussed this in the comments above. we concluded that these extensions would always be enabled and that other cert types would need to be explicitly enabled via init flags. That means that in this case raw public keys are only enabled when you pass the `ENABLE_RAWPK` flag. These extensions will only negotiate enabled cert types. In case only the default is enabled then these extensions will not send anything. This is default behaviour according to the spec. We also agreed on removed the old flag to enable these extensions explicitly because this is not needed anymore when we explicitly enable cert types via their own dedicated flags. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118859403 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 21:57:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 20:57:11 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed I've been taught to write down (i.e. comment) the major steps that you are performing in the code to improve readability and ease of reasoning about the code. The rule of thumb is that approx. 50% of good code consists of comments. Of course this number is debatable but in general I think you can rarely have too much comments. In my opinion it doesn't harm and it doesn't influence the resulting binary. Looking at your comments you seem to dislike too much comments. What is your opinion about code comments? What standards should I follow? BTW: what does the abbreviation "nit" mean? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118860803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 21:58:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 20:58:01 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/client_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > const version_entry_st* vers = get_version(session); > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) See my comment above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118860947 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:02:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:02:59 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > > } > > + > +/* Locates the first certificate that holds a raw public-key. For me a certificate is just a container for cryptographic credentials. There are all kinds of certificates. TLS has been designed around X.509 but I think we can generalize from this. Whether you call a raw public-key a certificate or not depends on taste I guess. In the comment I explicitly call this a certificate because we are inspecting a certificate credential that holds a certificate list of which the certificate(s) (i.e. the contents) only contain a raw public-key. Please let me know whether (after my explanation) you still want me to update the comment. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118861697 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:09:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:09:01 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > + const gnutls_certificate_credentials_t cred, > + const gnutls_pk_algorithm_t* pk_algos, > + int pk_algos_length, int* indx) > +{ > + unsigned i; > + gnutls_pk_algorithm_t pk; > + > + *indx = -1; > + > + // Traverse all certificate credentials > + for (i = 0; i < cred->ncerts; i++) { > + /* We know that our list length will be 1, therefore we can > + * ignore the rest. > + */ > + if (cred->certs[i].cert_list_length == 1) { > + // If the *_SIGN algorithm and cert type match the cert is our cert! Good catch. This comment and corresponding code is actually partially copied from your code in `find_x509_client_cert`. I will update the comment in both places. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118862811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:15:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:15:58 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > +} > + > + > int > _gnutls_gen_cert_client_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.client_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the client > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); I don't see this function as an external API only. The benefit of calling this function is that if we decide to change the internal structure of the values that this function retrieves we don't have to update all the parts of the code that access these values but only have to update this function. Since I've dealt with internal structure changes a couple of times since I've been working on this project I see a great benefit of my approach ;-). What do see as a disadvantage of calling this function? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118863719 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:21:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:21:35 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/session.c: > - } else { > - // print proto version, client cert type, server cert type > - snprintf(proto_name, sizeof(proto_name), "%s-%s-%s", > - gnutls_protocol_get_name(get_num_version(session)), > - gnutls_certificate_type_get_name(ctype_client), > - gnutls_certificate_type_get_name(ctype_server)); > - } > - } else { // Assumed default certificate type (X.509) > - snprintf(proto_name, sizeof(proto_name), "%s", > - gnutls_protocol_get_name(get_num_version > - (session))); > + // Get certificate types > + ctype_client = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > + ctype_server = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > + > + if (ctype_client == ctype_server) { It is because these values are both set to X509 as a default. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118864499 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:26:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:26:24 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert.h: > +/* Indeed. I will update this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118865109 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:27:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:27:58 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > return GNUTLS_E_INSUFFICIENT_CREDENTIALS; > } > > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); Yes, to avoid the need to update all the places in the code where this field is accessed in case of a structure change. See my previous comment about this issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118865294 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 20 22:29:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 20 Nov 2018 21:29:28 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: I have also reported the issue at Wine's bug tracker and they are also working on a fix on Wine's side. But preventing applications from setting an incorrect set of proposals is probably a good idea regardless. Thank you very much for your awesome work! Wine issue for reference: https://bugs.winehq.org/show_bug.cgi?id=46161 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621#note_118865486 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 09:18:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 08:18:59 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > +} > + > + > int > _gnutls_gen_cert_client_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.client_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the client > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); While the overhead of a function is not significant, a server doing millions of x509 sessions will have to call this function several million times instead of accessing a variable available to it. On similar occasions we used static inline functions (see for example `get_version()`). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118959632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 09:21:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 08:21:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > typedef enum CertificateSigType { RSA_SIGN = 1, DSA_SIGN = 2, ECDSA_SIGN = 64 > } CertificateSigType; > > -/* Moves data from a internal certificate struct (gnutls_pcert_st) to > +/* Moves data from an internal certificate struct (gnutls_pcert_st) to > * another internal certificate struct (cert_auth_info_t), and deinitializes > * the former. > */ > int _gnutls_pcert_to_auth_info(cert_auth_info_t info, gnutls_pcert_st * certs, size_t ncerts) > { > + /* REMARK: why do we free certs here? It is unexpected behavior and might be undesireable Indeed that function could have been different, but it is not :) There is only one caller so I guess it is modeled after the needs of this caller. It looks also like a good candidate to make static. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118960712 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 09:25:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 08:25:35 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/tls13-cert-key-exchange.c: > { > global_init(); > > - server_priority = "NORMAL:+ANON-DH:+ANON-ECDH:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+ECDHE-ECDSA:+CURVE-X25519:+SIGN-EDDSA-ED25519"; > - try("TLS 1.3 with ffdhe2048 rsa no-cli-cert / anon on server", "NORMAL:-VERS-ALL:+VERS-TLS1.3:-GROUP-ALL:+GROUP-FFDHE2048", GNUTLS_KX_DHE_RSA, GNUTLS_SIGN_RSA_PSS_RSAE_SHA256, GNUTLS_SIGN_UNKNOWN); > + server_priority = "NORMAL:+ANON-DH:+ANON-ECDH:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+ECDHE-RSA:+DHE-RSA:+RSA:+ECDHE-ECDSA:+CURVE-X25519:+SIGN-EDDSA-ED25519"; //REMARK: why are we working with globals here? That's how the test it was based on can update the server's priority string. I guess it was done to save passing another parameter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118961715 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 09:26:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 08:26:09 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I think I have answered the remarks. Let me know when the code is ready for review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_118961893 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 12:54:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 11:54:13 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Just a suggestion: - test scripts use `/bin/sh` in the shebang - we add a function in `tests/scripts/common.sh` that exits with 77 (SKIP) if not running on bash. Let's name is `skip_if_not_bash()`. - add a call to skip_if_not_bash() for scripts that require bash That means devs can focus on writing test scripts for bash. If they break the Alpine runner, the dev just adds a call to skip_if_not_bash() *or* fixes the bashism. Whatever suits best. If later someone comes up with fixes for bashisms, especially when those are trivial, they should be accepted since they improve the situation. This MR has more than fixing bashisms. There is also a signal/abort (SIGABRT) issue being fixed. And several usages of diff options (-I) have been replaced by grep. This is also pretty trivial. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119038871 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 13:27:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 12:27:35 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: @lumag would you mind taking a review of this? I guess I can't ask Tim for review, as it mainly contains the changes in !645 written by him. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_119048236 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 15:21:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 14:21:06 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Darshit Shah started a new discussion on tests/cert-tests/certtool: > -#!/usr/bin/env bash > +#!/bin/sh I don't think this is a good idea. It's better to leave it as `/usr/bin/env sh`. `env` is always available and is the safe way to pick the right shell. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119083729 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 15:24:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 14:24:24 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Thanks! I will give you a heads-up. Could you reply to my comments on the issues from your review of the first commit? Then I know how to handle things for the final version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119084716 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 15:33:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 14:33:22 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Darshit Shah commented on a discussion on tests/cert-tests/certtool: > exit 1 > fi > > - #check whether ask-pass is being honoured > - ${SETSID} "${CERTTOOL}" --generate-self-signed --load-privkey ${TMPFILE1} --template "${srcdir}/templates/template-test.tmpl" --ask-pass >${TMPFILE2} 2>&1 <<<${PASS} > + #check whether password is being honoured Why do you need to skip this test? The fix to the bashism here is very simple: ``` ${SETSID} "${CERTTOOL}" --generate-self-signed --load-privkey ${TMPFILE1} --template "${srcdir}/templates/template-test.tmpl" --ask-pass >${TMPFILE2} 2>&1 < From gnutls-devel at lists.gnutls.org Wed Nov 21 17:10:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 16:10:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > typedef enum CertificateSigType { RSA_SIGN = 1, DSA_SIGN = 2, ECDSA_SIGN = 64 > } CertificateSigType; > > -/* Moves data from a internal certificate struct (gnutls_pcert_st) to > +/* Moves data from an internal certificate struct (gnutls_pcert_st) to > * another internal certificate struct (cert_auth_info_t), and deinitializes > * the former. > */ > int _gnutls_pcert_to_auth_info(cert_auth_info_t info, gnutls_pcert_st * certs, size_t ncerts) > { > + /* REMARK: why do we free certs here? It is unexpected behavior and might be undesireable It has two callers now actually. And its going to be three when we also have krb support. I think it might be good to split this file into separate files that handle different cert types each. But I propose to do that in a separate cleanup patch. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119126142 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 17:15:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 16:15:00 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check > + if (cred->certs[0].cert_list_length > 0 && Why do you think that? Can we be sure that `cert_list[0]` always exists? This check prevents a potential memory error. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119127376 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 17:30:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 16:30:13 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on .gitignore: > *.trs > win32 > win64 > +*.orig It can go in a cleanup patch if you like? I think its good to have it in gitignore to prevent accidental adding of these files. The ability to remove them holds for all items in the gitignore file. You just don't want to do it every time. Sometimes you even want to keep the files as backup. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119133072 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 17:40:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 16:40:09 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > struct gnutls_openpgp_keyring_int; > typedef struct gnutls_openpgp_keyring_int *gnutls_openpgp_keyring_t; > > +/* Raw public key types */ > +struct gnutls_rawpubkey_st; > +typedef struct gnutls_rawpubkey_st* gnutls_rawpubkey_t; Nice catch. This is old stuff and can be removed altogether. Fixed it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119136790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 17:53:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 16:53:11 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > * certificate and then check its compatibility with > * the ciphersuites. > */ > - > - /* If the callback which retrieves the certificate has been set, Because the comment above says the same. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119140251 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:04:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:04:18 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > - we add a function in `tests/scripts/common.sh` that exits with 77 (SKIP) if not running on bash. Let's name is `skip_if_not_bash()`. > - add a call to skip_if_not_bash() for scripts that require bash Wouldn't that mean that these tests will run only if `/bin/sh` is bash? In the freebsd runners bash is `/usr/local/bin/bash` and these tests are currently running there. With the new approach they will not. > That means devs can focus on writing test scripts for bash. If they break the Alpine runner, the dev just adds a call to skip_if_not_bash() _or_ fixes the bashism. Whatever suits best. Why cannot we install bash on alpine? > This MR has more than fixing bashisms. There is also a signal/abort (SIGABRT) issue being fixed. And several usages of diff options (-I) have been replaced by grep. This is also pretty trivial. Ok, let me check it in detail. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119164608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:06:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:06:19 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/certtool: > exit 1 > fi > > - #check whether ask-pass is being honoured > - ${SETSID} "${CERTTOOL}" --generate-self-signed --load-privkey ${TMPFILE1} --template "${srcdir}/templates/template-test.tmpl" --ask-pass >${TMPFILE2} 2>&1 <<<${PASS} > + #check whether password is being honoured This was first my first try. It didn't work on Alpine. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119164909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:14:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:14:38 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > Wouldn't that mean that these tests will run only if /bin/sh is bash? In the freebsd runners bash is /usr/local/bin/bash and these tests are currently running there. With the new approach they will not. It was just an idea. We could also (or instead) try to find bash (if not already running in bash) with `which bash` and restart the script with bash if found. > Why cannot we install bash on alpine? Of course we can. But do you want to tell each user (s)he should first install bash and link /bin/sh to it ? IMO, the less the dependencies the easier someone can build + test + use GnuTLS on slim systems like Alpine. Alpine becomes more and more popular for docker images. This is true for other tiny (container-optimzed) distros. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119166050 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:30 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/certtool: > -#!/usr/bin/env bash > +#!/bin/sh I agree. But we should have it identical over all scripts. That clearly is a different issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175741 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:55 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/certtool-eddsa: > DIFF="${DIFF:-diff -b -B}" > KEYFILE=eddsa-privkey.$$.tmp > TMPFILE=eddsa.$$.tmp > +TMPFILE2=eddsa.$$.tmp2 Please use '.tmp' as suffix so an 'rm -f *.tmp' will remove all these files. It can be 'eddsa2.$$.tmp' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:58 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/scripts/common.sh: > } > > # Find a port number not currently in use. > -GETPORT='rc=0; myrandom=$(date +%N | sed s/^0*//) > +GETPORT='rc=0; unset myrandom > + if test -n "$RANDOM"; then myrandom=$(($RANDOM + $RANDOM)); fi > + if test -z "$myrandom"; then myrandom=$(date +%N | sed s/^0*//); fi > + if test -z "$myrandom"; then myrandom=0; fi why use zero here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175828 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:58 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/long-crl.sh: > TMPFILE=long.$$.pem.tmp > > rm -f $TMPFILE > -${VALGRIND} "${CERTTOOL}" --crl-info --inder --infile "${srcdir}/data/long.crl" --outfile $TMPFILE > +${VALGRIND} "${CERTTOOL}" --crl-info --inder --infile "${srcdir}/data/long.crl" --outfile $TMPFILE"x" what if we use a new variable here (TMPFILE2) or so? That would allow using a file with extension '.tmp' similarly to the other. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:55 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pkcs12-utf8: > -#!/usr/bin/env bash > +#!/bin/sh This will not run on freebsd with bash -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175822 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:56 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ Hmmm, what is not tested here is whether abort was actually called. Maybe a portable way would be to use the same method as used in `tls13/prf.c`, ie., override the abort() call, using something that sets `error_detected=1`. That way we will not rely on the signal at all. I guess if `tls13/prf.c` works on alpine, that would work too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:56 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on .gitlab-ci.yml: > except: > - tags > artifacts: > - expire_in: 1 week > + expire_in: 2 weeks shouldn't we make that consistent to all builds? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:56 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pem-decoding: > exit ${rc} > fi > > -cat "${srcdir}/data/complex-cert.pem" |grep -v "Not After:" >${TMPFILE1} > -cat ${TMPFILE} |grep -v "Not After:" >${TMPFILE2} > -${DIFF} -I 'Algorithm Security Level' ${TMPFILE1} ${TMPFILE2} || ${DIFF} -I 'Algorithm Security Level' --strip-trailing-cr ${TMPFILE1} ${TMPFILE2} > +grep -v "Not After:" "${srcdir}/data/complex-cert.pem" >${TMPFILE1} > +grep -v "Not After:" ${TMPFILE} >${TMPFILE2} The `Algorithm Security Level` seems to be missed here and in some of the following. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175825 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:58 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/certtool-ecdsa: > exit 1 > fi > > -$DIFF -I 'Not After:' ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" > +$DIFF ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" That should actually ignore not the 'Not after', but the algorithm security level for the same reason as the others. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:57 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on .gitlab-ci.yml: > > Debian.cross.aarch64-linux-gnu: > <<: *Debian_cross_template > + > +# Test building from tarball in a non-dev environment > +Tarball: > + stage: stage2-tarball > + image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$ALPINE_BASE_BUILD Having the alpine run on stage2 it would mean that any failure which is alpine specific will be detected only after the first stage is completely run (1h+ for stage1). Should we add alpine to stage1 and use debian or fedora here (that would address the commented part below with clean)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175829 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:34:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:34:55 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pem-decoding: > exit ${rc} > fi > > -cat "${srcdir}/data/xmpp-othername.pem" |grep -v "Not After:" >${TMPFILE1} > -cat ${TMPFILE} |grep -v "Not After:" >${TMPFILE2} > -${DIFF} -I ^warning -I 'Algorithm Security Level' ${TMPFILE1} ${TMPFILE2} || ${DIFF} -I 'Algorithm Security Level' --strip-trailing-cr ${TMPFILE1} ${TMPFILE2} > +grep -v "Not After:" "${srcdir}/data/xmpp-othername.pem" >${TMPFILE1} > +egrep -v '^warning|Not After:' ${TMPFILE} >${TMPFILE2} What about simulating the `DIFF -I` using a function call? This would not only simplify the use but also can be portable (it could even eliminate the need for `tr -d '\r'`). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119175823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:39:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:39:36 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/pkcs12-utf8: > -#!/usr/bin/env bash > +#!/bin/sh Can't test without a FreeBSD CI. Will `#!/usr/bin/env sh` do it ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119176601 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:40:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:40:57 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > typedef enum CertificateSigType { RSA_SIGN = 1, DSA_SIGN = 2, ECDSA_SIGN = 64 > } CertificateSigType; > > -/* Moves data from a internal certificate struct (gnutls_pcert_st) to > +/* Moves data from an internal certificate struct (gnutls_pcert_st) to > * another internal certificate struct (cert_auth_info_t), and deinitializes > * the former. > */ > int _gnutls_pcert_to_auth_info(cert_auth_info_t info, gnutls_pcert_st * certs, size_t ncerts) > { > + /* REMARK: why do we free certs here? It is unexpected behavior and might be undesireable Makes sense to me -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119176771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:41:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:41:14 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ It will be tested if abort() was called. That's the whole idea. abort() aborts the program with a non-0 status code. So if an assert() is being triggered, the test fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119176820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:41:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:41:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check > + if (cred->certs[0].cert_list_length > 0 && Can we have `cred->ncerts == 1` and `cred->certs[0].cert_list_length == 0`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119176879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:42:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:42:34 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ Sorry other way round... the expected assert() makes the test survive. If it is not triggered, fail() will be called. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119176976 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:47:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:47:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed `nit` is from nit-picking. My experience with comments is that they get old and unrelated with the code. They can also be used as an excuse to write unreadable code. Good clean code shouldn't need any comments to be readable in my opinion, and you can see that in well-written projects like systemd, where the number of comments is very low, while the readability is high. The examples I mentioned the comments were actually distracting, for example: ``` //free the pointer free(p); ``` There is no information added by the comment which cannot be inferred by reading the code. I'd expect a comment to be useful when doing something complicated, or when doing something that is not obvious by reading the code. E.g. ``` *0xff03a3 = 3; ``` needs a comment. The `free(p)` is obvious to someone in the project. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119177846 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:54:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:54:19 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed btw. we don't have any suggestions on commenting style on CONTRIBUTION.md. Maybe we should introduce something. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119179572 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:56:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:56:16 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > > } > > + > +/* Locates the first certificate that holds a raw public-key. It would be very confusing in that code base if we use certificate for that. All text on X.509 certificates, uses just "certificate", so we would need to differentiate. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119179874 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 20:57:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 19:57:04 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/client_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > const version_entry_st* vers = get_version(session); > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) The comment I see above seems unrelated. Could you elaborate here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119180755 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 21:12:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 20:12:15 +0000 Subject: [gnutls-devel] GnuTLS | CONTRIBUTING.md: added proposal on commenting style [ci skip] (!816) References: Message-ID: New Merge Request !816 https://gitlab.com/gnutls/gnutls/merge_requests/816 Branches: tmp-comment-style to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This brings a proposal on commenting style. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 21:16:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 20:16:42 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/scripts/common.sh: > } > > # Find a port number not currently in use. > -GETPORT='rc=0; myrandom=$(date +%N | sed s/^0*//) > +GETPORT='rc=0; unset myrandom > + if test -n "$RANDOM"; then myrandom=$(($RANDOM + $RANDOM)); fi > + if test -z "$myrandom"; then myrandom=$(date +%N | sed s/^0*//); fi > + if test -z "$myrandom"; then myrandom=0; fi That's a fallback in case we can't get a random value. It means that we try getting an unused port based starting at `PID % 63001 + 2000`, which is IMO quite OK. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119183599 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 21 21:46:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 21 Nov 2018 20:46:56 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/certtool-ecdsa: > exit 1 > fi > > -$DIFF -I 'Not After:' ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" > +$DIFF ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" If have it ready - is it ok to add in common.sh ? ``` # $1, $2: the two files to check for equality # $3: Strings to be ignored, separated by | assert_equal() { local tmp1=`basename "$1"` local tmp2=`basename "$2"` if test -n "$3"; then local tmp1=`basename "$1"`"1.tmp" local tmp2=`basename "$2"`"2.tmp" grep -v "$3" "$1" | tr -d '\r' >"$tmp1" grep -v "$3" "$2" | tr -d '\r' >"$tmp2" diff "$tmp1" "$tmp2" local rc=$? rm -f "$tmp1" "$tmp2" return $rc fi diff "$1" "$2" return $? } ``` Using it as ``` assert_equal ${TMPFILE} "${srcdir}/data/cert-eddsa.pem" "Not After:" if test $? != 0; then ... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119187485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 07:27:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 06:27:21 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion on tests/cert-tests/pkcs12-utf8: > -#!/usr/bin/env bash > +#!/bin/sh `#!/usr/bin/env sh do it ?` would only work if bash was installed in the path under the name sh. Which is often (Debian and derivatives, too) not the case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119240732 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 08:51:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 07:51:59 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/pkcs12-utf8: > -#!/usr/bin/env bash > +#!/bin/sh The script works well without bash, just with a POSIX shell. So the question was if the script works with FreeBSD's 'sh' as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119253300 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 08:52:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 07:52:52 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style (!816) In-Reply-To: References: Message-ID: Marked as WIP so that we can discuss it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_119253453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 09:04:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 08:04:28 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on src/certtool.c: > - fprintf(stderr, "export error: %s\n", > - gnutls_strerror(ret)); > - app_exit(1); > - } > - > - fwrite(lbuffer, 1, size, outfile); > - > - gnutls_pubkey_deinit(pubkey); > - > - return; > - } > - > - /* PEM */ > - > - _pubkey_info(outfile, full_format, pubkey); > + print_pubkey_info(pubkey, outfile, full_format, outcert_format, cinfo->outtext); why didn't you pass `cinfo` in that case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119258172 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 09:05:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 08:05:04 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pem-decoding: > +#check if --no-text works as expected > +${VALGRIND} "${CERTTOOL}" --certificate-info --infile "${srcdir}/data/cert-ecc256.pem" --no-text >${TMPFILE} > +rc=$? > + > +if test "${rc}" != "0"; then > + echo "--no-text -k --certificate-info failed 1" > + exit ${rc} > +fi > + > +if ( head -n 1 ${TMPFILE} ; tail -n 1 ${TMPFILE} ) | grep -v -- ----- > +then > + echo "--no-text -k --certificate-info failed 2" > + exit 1 > +fi > + > +#check if --no-text works as expected should we also test here that if output type is DER, no textual data is added? That was a common regression in the past. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119258371 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 09:06:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 08:06:06 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Great cleanup! Apart from the comments above, it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119258700 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 09:42:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 08:42:28 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > > Wouldn't that mean that these tests will run only if /bin/sh is bash? In the freebsd runners bash is /usr/local/bin/bash and these tests are currently running there. With the new approach they will not. It was just an idea. We could also (or instead) try to find bash (if not already running in bash) with `which bash` and restart the script with bash if found. > > Why cannot we install bash on alpine? > Of course we can. But do you want to tell each user (s)he should first install bash and link /bin/sh to it ? But that's not the situation today. To run the test suite bash is required and it doesn't need to be in `/bin/sh` (that's why env is used). To run gnutls tools or use the library itself no bash is required. We may have different users in mind, but I see a normal user as someone who downloads gnutls from its distribution, and the test suite being more relevant to people porting gnutls to various platforms, or building for a distribution. When building gnutls we already require several devel packages make/gcc/libtasn1-devel/p11-kit-devel/libidn2-devel/cmocka-devel and when building from git even more like autogen/gperf, so I do not see requiring bash for running the test suite a big obstacle for running the test suite. > IMO, the less the dependencies the easier someone can build + test + use GnuTLS on slim systems like Alpine. Alpine becomes more and more popular for docker images. This is true for other tiny (container-optimzed) distros. Certainly, and thank you for bringing that support. We want to run gnutls there and test it there. What I'm questioning is whether we should strive to make gnutls testable with only the default shell of alpine. Even if we make bash scripts optional and disabled on that platform (e.g., in Makefile.am), that would mean this platform a second-class citizen because not all tests will be run. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119276134 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 10:27:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 09:27:22 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/cert-tests/certtool-ecdsa: > exit 1 > fi > > -$DIFF -I 'Not After:' ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" > +$DIFF ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" I don't intend to bikeshed, but in the future it might be worth considering the use of [init.sh](http://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/init.sh) from gnulib, which has a function `compare_` among many other goodies for portability. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119290598 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 12:58:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 11:58:23 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > To run the test suite bash is required and it doesn't need to be in /bin/sh (that's why env is used). Can't see any usage of env except in one test. Maybe it is a future plan to use it (we should open an issue about it). It's a different thing, not directly related to this MR. But when at it: `#!/usr/sbin/env sh` as proposed won't start bash. It just finds sh even when not in /bin. > I see a normal user as someone who downloads gnutls from its distribution That's one type of user. There are several other types. And there are OSes that don't have latest GnuTLS in their repos. There are container builds, manual and automated, striving for a minimal build environment. Non of these is interested in a full-blown developer build with TLS fuzzer testing etc. All that is required is a `./configure && make && make check` - and the 'check' is just to test the basic functionality. If this can be run with a simple POSIX shell (and the busybox ash is maybe the best we can have here) just with trivial changes... well, then we should do it. If people want more - they should just install bash. we can easily document it. This MR does it (the requested changes will likely be addressed tomorrow, when I have some time). And talking about future bash-only scripts is a bit theoretical right now. Let's discuss those test when they arrive to leave the academical area and go back to practice. And BTW, I never said that requiring bash is a *big obstacle*. It's just a small annoyance. So, there is no second-class platform when applying this MR (no single script *really* requires bash yet). And for the future of bash-only scripts I suggest to wait & see. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119343457 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 14:26:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 13:26:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed Alright, thanks for explaining. > My experience with comments is that they get old and become unrelated with the code over time. Of course comments should be updated when the code is updated. But I can imagine that this is not always the case. My experience is that most developers don't like to write a lot of comments but rather spend their time on features. Anyway, do you want me to remove all the comments that you marked superfluous? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119371734 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 14:29:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 13:29:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/client_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > const version_entry_st* vers = get_version(session); > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) I was referring to a couple of discussions above this one ;-). The one where you first addressed this issue. I quote my reaction here: > We discussed this in the comments above (from your first review). we concluded that these extensions would always be enabled and that other cert types would need to be explicitly enabled via init flags. That means that in this case raw public keys are only enabled when you pass the `ENABLE_RAWPK` flag. These extensions will only negotiate enabled cert types. In case only the default is enabled then these extensions will not send anything. This is default behaviour according to the spec. We also agreed on removed the old flag to enable these extensions explicitly because this is not needed anymore when we explicitly enable cert types via their own dedicated flags. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119373137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 15:17:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 14:17:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: record: make CCS handling stricter in TLS 1.3 (!817) References: Message-ID: New Merge Request !817 https://gitlab.com/gnutls/gnutls/merge_requests/817 Branches: tmp-ccs-tls13 to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes #618, and minor build issues. ## Checklist * [ ] 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/817 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 15:17:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 14:17:58 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert description in Alert Message (#618) In-Reply-To: References: Message-ID: Reassigned Issue 618 https://gitlab.com/gnutls/gnutls/issues/618 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 17:41:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 16:41:07 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/pcert.c: > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.4 > + **/ > +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert, > + gnutls_pubkey_t pubkey, unsigned int flags) > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + // Check whether a valid pointer to a public key is passed Yes, please. It would be good to keep the comments that matter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119428993 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 17:51:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 16:51:49 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/client_cert_type.c: > uint8_t i = 0, num_cert_types = 0; > priority_st* cert_priorities; > gnutls_datum_t tmp_cert_types; // For type conversion > - uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types > + uint8_t cert_types[GNUTLS_CRT_MAX]; // The list with supported cert types. Inv: 0 <= cert type Id < 256 > const version_entry_st* vers = get_version(session); > > - /* Only activate this extension if cert type negotiation is enabled > - * and we have cert credentials set */ > - if (!_gnutls_has_negotiate_ctypes(session) || > - _gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) > + /* Only activate this extension if we have cert credentials set */ > + if (_gnutls_get_cred(session, GNUTLS_CRD_CERTIFICATE) == NULL) There is no reason to parse or even try to send this extension at all, when the application hasn't enable any alternative certificate types, so it shouldn't. The `_gnutls_has_negotiate_ctypes` could check whether any alt cert flag is enabled. Why is that? So that the attack surface is reduced for applications which do not enable that feature. Applications should expose only what they use. A prominent example of what can go wrong is the heartbleed attack in openssl; they enabled the heartbeat extension even for applications not using them. There was a buffer overflow there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119431629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 22 19:41:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 22 Nov 2018 18:41:30 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: > > To run the test suite bash is required and it doesn't need to be in /bin/sh (that's why env is used). > Can't see any usage of env except in one test. Maybe it is a future plan to use it (we should open an issue about it). It's a different thing, not directly related to this MR. But when at it: `#!/usr/sbin/env sh` as proposed won't start bash. It just finds sh even when not in /bin. We do not have any script with `#!/usr/sbin/env sh`. We have `#!/usr/sbin/env bash` in `cert-tests/pkcs12-utf8`, `cert-tests/certtool`, and `gnutls-cli-debug.sh`. > That's one type of user. There are several other types. And there are OSes that don't have latest GnuTLS in their repos. There are container builds, manual and automated, striving for a minimal build environment. Non of these is interested in a full-blown developer build with TLS fuzzer testing etc. All that is required is a `./configure && make && make check` - and the 'check' is just to test the basic functionality. If this can be run with a simple POSIX shell (and the busybox ash is maybe the best we can have here) just with trivial changes... well, then we should do it. If people want more - they should just install bash. we can easily document it. Optional tests are a necessary evil and I do not think we should be introducing them, unless it is really necessary. It is very easy to skip them on an CI upgrade for example if the underlying OS changes some of the assumptions. > This MR does it (the requested changes will likely be addressed tomorrow, when I have some time). And talking about future bash-only scripts is a bit theoretical right now. Let's discuss those test when they arrive to leave the academical area and go back to practice. And BTW, I never said that requiring bash is a _big obstacle_. It's just a small annoyance. Ok, I may be going into a bikeshedding area, so ok, if we can remove the bash as a dependency lets try it. But we should have easy macros to achieve the same functionality and let's remove them completely (i.e., not make some of these tests optional). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119452744 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 01:29:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 00:29:06 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on src/certtool.c: > - fprintf(stderr, "export error: %s\n", > - gnutls_strerror(ret)); > - app_exit(1); > - } > - > - fwrite(lbuffer, 1, size, outfile); > - > - gnutls_pubkey_deinit(pubkey); > - > - return; > - } > - > - /* PEM */ > - > - _pubkey_info(outfile, full_format, pubkey); > + print_pubkey_info(pubkey, outfile, full_format, outcert_format, cinfo->outtext); Because `print_pubkey_info` is also used in `tpmtool.c` which does not use `common_info_t`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119508317 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 01:29:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 00:29:36 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on tests/cert-tests/pem-decoding: > +#check if --no-text works as expected > +${VALGRIND} "${CERTTOOL}" --certificate-info --infile "${srcdir}/data/cert-ecc256.pem" --no-text >${TMPFILE} > +rc=$? > + > +if test "${rc}" != "0"; then > + echo "--no-text -k --certificate-info failed 1" > + exit ${rc} > +fi > + > +if ( head -n 1 ${TMPFILE} ; tail -n 1 ${TMPFILE} ) | grep -v -- ----- > +then > + echo "--no-text -k --certificate-info failed 2" > + exit 1 > +fi > + > +#check if --no-text works as expected This would be harder to test. Any suggestions other than using `cmp` command? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119508346 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 01:30:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 00:30:36 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: All discussions on Merge Request !808 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/808 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 01:54:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 00:54:49 +0000 Subject: [gnutls-devel] GnuTLS | Add support for signed PKCS#12 (#620) In-Reply-To: References: Message-ID: Reassigned Issue 620 https://gitlab.com/gnutls/gnutls/issues/620 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/620 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 02:19:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 01:19:05 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: @dueno I like the idea. My only problem with the implementation is the following. Consider a user who has Autogen installed, but with a version incompatible with the one used to generate the in-tarball sources. Currently such case is handled automatically, with your changes user will have to manually remove `.stamp` files to enforce regeneration. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_119510948 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 09:54:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 08:54:24 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/cert-tests/pem-decoding: > +#check if --no-text works as expected > +${VALGRIND} "${CERTTOOL}" --certificate-info --infile "${srcdir}/data/cert-ecc256.pem" --no-text >${TMPFILE} > +rc=$? > + > +if test "${rc}" != "0"; then > + echo "--no-text -k --certificate-info failed 1" > + exit ${rc} > +fi > + > +if ( head -n 1 ${TMPFILE} ; tail -n 1 ${TMPFILE} ) | grep -v -- ----- > +then > + echo "--no-text -k --certificate-info failed 2" > + exit 1 > +fi > + > +#check if --no-text works as expected What about grepping for "----BEGIN"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119558114 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 10:26:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 09:26:35 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: I guess such situation could be effectively avoided if: - we check the installed libopts version and - fallback to use the bundled libopts if the system libopts is older Still, the user might want to link against the (older) system libopts. In that case, however, I think he wouldn't mind removing `.stamp` manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_119567116 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 11:00:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 10:00:24 +0000 Subject: [gnutls-devel] GnuTLS | record: make CCS handling stricter in TLS 1.3 (!817) In-Reply-To: References: Message-ID: Although the self-test might not be sufficient, I've confirmed that it fixes the failure with the tlsfuzzer script (test-tls13-ccs.py). Marking as blocked until the script is merged in tlsfuzzer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/817#note_119576728 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 13:10:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 12:10:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/cert_types.h: > switch (cert_type) { > case GNUTLS_CRT_X509: > return 0; > + case GNUTLS_CRT_RAWPK: > + return 2; > default: > return GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE; > } > } > + > +/* Checks whether the given cert type is enabled in the application > + */ > +static inline bool _gnutls_is_cert_type_enabled(gnutls_session_t session, gnutls_certificate_type_t cert_type) In general it is good practise to make function definitions in header files static inline. This does not imply that this function is only used within only one translation unit (since the header file can be included in different modules). Therefore I think we should keep the prefix. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119613208 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 14:01:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 13:01:14 +0000 Subject: [gnutls-devel] GnuTLS | record: make CCS handling stricter in TLS 1.3 (!817) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > _mbuffer_head_remove_bytes(&session->internals.record_recv_buffer, > record.header_size + record.length); > > + /* protected CCS is not allowed in TLS 1.3 */ There is a similar check in `record_add_to_buffers` for DTLS, should we combine them? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/817#note_119624644 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 14:54:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 13:54:12 +0000 Subject: [gnutls-devel] GnuTLS | record: make CCS handling stricter in TLS 1.3 (!817) In-Reply-To: References: Message-ID: All discussions on Merge Request !817 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/817 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/817 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 14:54:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 13:54:14 +0000 Subject: [gnutls-devel] GnuTLS | record: make CCS handling stricter in TLS 1.3 (!817) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/record.c: > _mbuffer_head_remove_bytes(&session->internals.record_recv_buffer, > record.header_size + record.length); > > + /* protected CCS is not allowed in TLS 1.3 */ Yes, actually the check in `record_add_to_buffers` is: ```c case GNUTLS_CHANGE_CIPHER_SPEC: if (!(IS_DTLS(session))) { ret = gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET); goto cleanup; } ``` so protected CCS are already rejected. I removed the check in `_gnutls_recv_in_buffers`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/817#note_119638437 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 15:01:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 14:01:14 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: I replaced the check of the existence of `autogen` command with `pkg-config --atleast-version=... autoopts` so it also requires recent enough version of libopts. As the `.pc` file was added in 5.6.5 (while we require 5.16), there shouldn't be compatibility issue with that regard. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_119640505 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 15:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 14:11:05 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @Vrancken since it is already week before the release, and we are still discussing items I think it is fair to postpone this feature for the next release. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119643014 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 15:18:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 14:18:31 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I think we can make it. I'm wrapping up the last things right now. If you have time to answer my last questions today then I have the final patch ready for the weekend. Don't know whether you are able to look at it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119644917 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 15:24:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 14:24:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check > + if (cred->certs[0].cert_list_length > 0 && I don't know. I can't oversee all possibilities. If we can not prove or guarantee this invariant then I would like to add an extra check just to be sure. How do you approach these kind of things? Since we are writing security code I tend to be better safe than sorry. I don't know whether extra checks cause to much overhead? If you want me to remove it I will. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119646942 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 15:57:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 14:57:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I can dedicate some time on Monday morning for reviewing it, though if there are issues could it you address them before wednesday? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119656396 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 16:26:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 15:26:56 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Yes I have time before Wednesday. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119663206 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 16:54:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 15:54:51 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS 3.6.4 based Gnome Web TLS error on site that Firefox does not complain about (#625) References: Message-ID: New Issue was created. Issue 625: https://gitlab.com/gnutls/gnutls/issues/625 Author: Aral Balkan Assignee: ## Description of problem: Started noticing that certain sites that Firefox does not complain about are being flagged as insecure by Gnome Web 3.30.1, which [I?m told uses GnuTLS](https://mstdn.fr/@mathieu/101121235551215322). ## Version of gnutls used: 3.6.4 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Pop!_OS 18.10 (based on Ubuntu 18.10) ## How reproducible: Steps to Reproduce: * Go to https://www.everymancork.com/ in Gnome Web * Go to https://www.everymancork.com/ in Firefox (version 63.0.3) ## Actual results: The site loads in Firefox, shows a TLS error on Gnome Web: ?This website?s identification was not issued by a trusted organisation.? ## Expected results: The results should match. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/625 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:08:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:08:04 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > + * where > + * length = 3 bytes and > + * certificate = length bytes. > + */ > + ret = _gnutls_buffer_append_data_prefix(data, 24, > + apr_cert_list[0].cert.data, > + apr_cert_list[0].cert.size); > + > + if (ret < 0) return gnutls_assert_val(ret); > + > + return data->length; > + } else { > + /* We found more than one certificate. In that case we don't know > + * which one to send, therefore we send nothing. > + */ > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); // TODO maybe introduce new error type GNUTLS_E_RAWPK_TOO_MANY_KEYS_GIVEN? It actually is an impossible situation. By using the rawpk API the cert list length of a raw public-key is always set to 1. I guess I was too cautious here with this extra check. Shall I insert an `assert` statement to reflect the invariant that `apr_cert_list_length == 1` should always hold? Or shall I just remove the if/else statement? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119678988 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:10:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:10:03 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > } > > - /* Correctly set the certificate type depending on whether we > - * have explicitly negotiated certificate types (RFC7250). > - */ > - if (_gnutls_has_negotiate_ctypes(session)) { > - if (IS_SERVER(session)) { > - type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > - } else { // Client mode > - type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > - } > - } else { > - type = DEFAULT_CERT_TYPE; > + /* Correctly set the certificate type */ > + if (IS_SERVER(session)) { > + type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); Well spotted. That would be a nice simplification. I'll update it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119679808 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:13:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:13:41 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/x509.h: > */ > > #include > -#include Because due to moving some function prototype declarations to other files, the declarations in `` are not needed here anymore. Just want to keep things clean. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119680826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:24:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:24:57 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > return ret; > } > > - if (apr_cert_list_length > 0) { > + if (apr_cert_list_length > 0) { // REMARK: is this check complete? What if there is a cert set but no corresponding priv key? We can't sign then. No they don't. So I guess this check should be sufficient then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119683035 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:37:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:37:19 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > > } > > + > +/* Locates the first certificate that holds a raw public-key. > + * Currently it only makes sense to associate one raw pubkey per session. > + * Associating more raw pubkeys with a session has no use because we > + * don't know how to select the correct one. > + */ > +static int > +find_rawpk_cert(gnutls_session_t session, It was not designed that way but currently it is. The structure of `_gnutls_select_client_cert` and `_gnutls_select_server_cert` differs currently too much to have `find_rawpk_cert` easily integrated into `_gnutls_select_server_cert`. We can change that in a cleanup patch and align the structure of the two functions. For now I will simply rename `find_rawpk_cert`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119686114 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:59:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:59:12 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS 3.6.4 based Gnome Web TLS error on site that Firefox does not complain about (#625) In-Reply-To: References: Message-ID: That is a matter if the issuer's CA cert is in your system trust store. E.g. in Debian (unstable) it is not available. You can download the CA cert from Comodo and install it locally. Firefox comes with it's own list of CA certs, while GnuTLS uses the certs/store configured by the application (Gnome Web). Chech here on Debian unstable: ``` $ gnutls-cli www.everymancork.com Processed 133 CA certificate(s). Resolving 'www.everymancork.com:443'... Connecting to '81.17.255.246:443'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=www.everymancork.com,OU=COMODO SSL,OU=Hosted by iPLANiT Ltd.,OU=Domain Control Validated', issuer `CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x06c9f1402a16b25ced3c5c143a3deec7, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-08-03 00:00:00 UTC', expires `2019-08-03 23:59:59 UTC', pin-sha256="0LqTpsw0MIz8uTX/15sP2Y48kxyZR9X9nbBy23HQREA=" Public Key ID: sha1:e836d9a0340612aad35ea7fccf071a12aa3744c7 sha256:d0ba93a6cc34308cfcb935ffd79b0fd98e3c931c9947d5fd9db072db71d04440 Public Key PIN: pin-sha256:0LqTpsw0MIz8uTX/15sP2Y48kxyZR9X9nbBy23HQREA= - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/625#note_119690206 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 17:59:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 16:59:13 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS 3.6.4 based Gnome Web TLS error on site that Firefox does not complain about (#625) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #625: https://gitlab.com/gnutls/gnutls/issues/625 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/625 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 18:28:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 17:28:13 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > + * don't know how to select the correct one. > + */ > +static int > +find_rawpk_cert(gnutls_session_t session, > + const gnutls_certificate_credentials_t cred, > + const gnutls_pk_algorithm_t* pk_algos, > + int pk_algos_length, int* indx) > +{ > + unsigned i; > + gnutls_pk_algorithm_t pk; > + > + *indx = -1; > + > + // Traverse all certificate credentials > + for (i = 0; i < cred->ncerts; i++) { > + /* We know that our list length will be 1, therefore we can I check it such that I can skip all certificates that have a list length other than 1. I don't have to inspect those to find a valid rawpk credential because I know that rawpk credentials always have a list length of 1. So basically it reduces the number of checks in the for loop. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119702969 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 20:07:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 19:07:25 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS 3.6.4 based Gnome Web TLS error on site that Firefox does not complain about (#625) In-Reply-To: References: Message-ID: The problem is actually that everymancork.com is not sending the intermediate certificate COMODO RSA Domain Validation Secure Server CA. This is not a root certificate and it's not supposed to be provided by the OS. It's supposed to be provided by everymancork.com. Firefox surely has it cached from a previous visit to some other website. [I wrote about this problem a while back.](https://blogs.gnome.org/mcatanzaro/2015/01/30/mozilla-is-responsible-for-the-redhat-corpmerchandise-com-fiasco/) Sadly, thanks to questionable choices by Firefox and Chrome, web compatibility nowadays requires verifying incomplete chains, which GnuTLS does not support. I'm actively working on #202 which should allow us to verify this incomplete chain. I recommend marking this issue as a duplicate of #202. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/625#note_119714907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 20:08:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 19:08:49 +0000 Subject: [gnutls-devel] GnuTLS | add a callback to retrieve missing chain certificates (#202) In-Reply-To: References: Message-ID: > I'm still planning to work on this soon, but still need to finish my work on that GNOME bug up above. Better late than never: I resolved that issue last week. Unfortunately there is a second regression from that change, which I am now working on. This is next. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/202#note_119715041 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 20:15:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 19:15:40 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: And I realized that what I write above is weird and does not make sense. What I meant to write is grepping for a known string of the textual form. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119715829 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 21:20:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 20:20:09 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/cert-tests/certtool-ecdsa: > exit 1 > fi > > -$DIFF -I 'Not After:' ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" > +$DIFF ${TMPFILE} "${srcdir}/data/cert-ecc256-full.pem" Thanks for the pointer. Let's consider this if we stumble upon serious portability issues. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119722910 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 23 21:30:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 23 Nov 2018 20:30:36 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on .gitlab-ci.yml: > > Debian.cross.aarch64-linux-gnu: > <<: *Debian_cross_template > + > +# Test building from tarball in a non-dev environment > +Tarball: > + stage: stage2-tarball > + image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$ALPINE_BASE_BUILD Or we think about / discuss a more radical change: - Use stage 1 with just one runner (Debian or Fedora) to build a tarball - Use stage 2 for tarball builds on different architectures / configurations We could improve CI speed by dividing the test suite into different smaller pieces (e.g. by using configure options) and run those test in parallel on stage 1. That of course changes the above plan a bit. That gives us a relatively fast stage1 with all the tests incl. the fuzzer ones. The runners in stage2 would just test basic functionality (e.g. not fuzzing) to also achieve a relatively fast finishing. If you like to discuss this a bit further, maybe an own issue would be appropriate. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119725836 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 06:02:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 05:02:09 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Reassigned Merge Request 810 https://gitlab.com/gnutls/gnutls/merge_requests/810 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 06:04:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 05:04:24 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/certtool.c: > - fprintf(stderr, "export error: %s\n", > - gnutls_strerror(ret)); > - app_exit(1); > - } > - > - fwrite(lbuffer, 1, size, outfile); > - > - gnutls_pubkey_deinit(pubkey); > - > - return; > - } > - > - /* PEM */ > - > - _pubkey_info(outfile, full_format, pubkey); > + print_pubkey_info(pubkey, outfile, full_format, outcert_format, cinfo->outtext); Hmm, I guess we should move it to it, though not necessarily on that fix. Ok. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119749809 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 06:11:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 05:11:18 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/cert-tests/pkcs7: > fi > done > > +${VALGRIND} "${CERTTOOL}" --inder --p7-info --infile "${srcdir}/data/full.p7b" --outfile "${TMPFILE}" --no-text > +rc=$? > + > +if test "${rc}" != "0"; then > + echo "--no-text pkcs7 info failed 1" > + exit ${rc} > +fi > + > +if ( head -n 1 ${TMPFILE} ; tail -n 1 ${TMPFILE} ) | grep -v -- ----- What is the intention here? Also the if with empty body seems quite strange. Why not use not, or the format above with checking $? for return code? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119750050 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 06:16:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 05:16:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: @stefanberger what about the questions above? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_119750238 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 06:27:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 05:27:14 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ I cannot seem to understand how does this work. I think we need either some comments documenting how is this supposed to work, or simplify it a little. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119750824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 10:47:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 09:47:42 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ I will add a comment/description. The short expl is that that call to gnutls_cipher_add_auth() is bad and should either end in an assert() in nettle or (if nettle was built with -NDEBUG) returns an error. If the assert() triggers, the (child) process abort()s and the parent recognizes the status code as OK (it was an expected failure). If the function returns 0/success, we call fail() because an error was expected. The testmode is to test different parts of the code. We could instead use three different functions, but that means a lot of code duplication. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119762485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 10:55:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 09:55:14 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) References: Message-ID: New Issue was created. Issue 626: https://gitlab.com/gnutls/gnutls/issues/626 Author: Tim R?hsen Assignee: Just stumbled upon this... ``` make[5]: Entering directory '/builds/gnutls/gnutls/build/lib/x509' CC common.lo CC key_encode.lo CC key_decode.lo CC time.lo CC crl.lo CC crl_write.lo CC crq.lo CC dn.lo CC attributes.lo CC prov-seed.lo CC extensions.lo CC mpi.lo CC output.lo CC pkcs12.lo CC pkcs12_bag.lo CC pkcs12_encr.lo CC pkcs7.lo CC pkcs7-attrs.lo CC pkcs7-crypt.lo CC privkey.lo CC privkey_pkcs8.lo CC privkey_pkcs8_pbes1.lo CC privkey_openssl.lo CC hostname-verify.lo CC sign.lo CC verify.lo CC x509.lo In file included from ../../../lib/x509/x509.c:38: ../../../lib/x509/../pkcs11_int.h: In function 'pk_to_mech': ../../../lib/x509/../pkcs11_int.h:230:24: error: 'CKM_EDDSA' undeclared (first use in this function); did you mean 'CKM_ECDSA'? return CKM_EDDSA; ^~~~~~~~~ CKM_ECDSA ../../../lib/x509/../pkcs11_int.h:230:24: note: each undeclared identifier is reported only once for each function it appears in ../../../lib/x509/../pkcs11_int.h: In function 'pk_to_key_type': ../../../lib/x509/../pkcs11_int.h:244:24: error: 'CKK_EC_EDWARDS' undeclared (first use in this function); did you mean 'CKA_EC_PARAMS'? return CKK_EC_EDWARDS; ^~~~~~~~~~~~~~ CKA_EC_PARAMS ../../../lib/x509/../pkcs11_int.h: In function 'key_type_to_pk': ../../../lib/x509/../pkcs11_int.h:257:23: error: 'CKK_EC_EDWARDS' undeclared (first use in this function); did you mean 'CKA_EC_PARAMS'? else if (m == CKK_EC_EDWARDS) ^~~~~~~~~~~~~~ CKA_EC_PARAMS ../../../lib/x509/../pkcs11_int.h: In function 'pk_to_genmech': ../../../lib/x509/../pkcs11_int.h:275:25: error: 'CKK_EC_EDWARDS' undeclared (first use in this function); did you mean 'CKA_EC_PARAMS'? *type = CKK_EC_EDWARDS; ^~~~~~~~~~~~~~ CKA_EC_PARAMS ../../../lib/x509/../pkcs11_int.h:276:24: error: 'CKM_EDDSA' undeclared (first use in this function); did you mean 'CKM_ECDSA'? return CKM_EDDSA; ^~~~~~~~~ CKM_ECDSA make[5]: *** [Makefile:1585: x509.lo] Error 1 make[5]: Leaving directory '/builds/gnutls/gnutls/build/lib/x509' make[4]: *** [Makefile:1464: all] Error 2 make[4]: Leaving directory '/builds/gnutls/gnutls/build/lib/x509' make[3]: *** [Makefile:2164: all-recursive] Error 1 make[3]: Leaving directory '/builds/gnutls/gnutls/build/lib' make[2]: *** [Makefile:1792: all] Error 2 make[2]: Leaving directory '/builds/gnutls/gnutls/build/lib' make[1]: *** [Makefile:1537: all-recursive] Error 1 make[1]: Leaving directory '/builds/gnutls/gnutls/build' make: *** [Makefile:1464: all] Error 2 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 15:51:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 14:51:13 +0000 Subject: [gnutls-devel] GnuTLS | tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on lib/tpm.c: > > if (attempts > 0) > flags |= GNUTLS_PIN_WRONG; > + else It probably should now be `attempts > 1`, if that's what you mean. The behavior without this patch is that `tpm_pin()` gets called after trying with the well-known SRK password first and if it fails calling `tpm_pin()` once, trying the TPM operationg, and then the flag is set when calling `tpm_pin()` again. We could also call tpm_pin() with a `0` the first time and count attempts after. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_119780045 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 16:06:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 15:06:04 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { > + /* either fails or calls abort() via assert(): */ I do not see where the parent recognizes the exit status of sigabort as ok. To the code currently listed, I see that any signal is interpreted as error. Do I miss something here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119780867 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 16:14:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 15:14:06 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .gitlab-ci.yml: > > Debian.cross.aarch64-linux-gnu: > <<: *Debian_cross_template > + > +# Test building from tarball in a non-dev environment > +Tarball: > + stage: stage2-tarball > + image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$ALPINE_BASE_BUILD The multiple stage build was used initially in gnutls (you can see how if you go back the history of .gitlab-ci.yml), but it was way to inefficient, and results from CI took several hours to finish. When the shared CI runners of gitlab became enough to afford parallelization I switched the CI to a single stage which dropped the run to ~1 hour. I think we are handling quite a number of separate pieces in this MR: 1. elimination of bashisms; this is orthogonal to alpine as it affects freebsd and debian as well 2. addition of alpine linux (with musl) to CI 3. testing of `make dist` and `make check` on the CI as separate stage (where this discussion about separate stages belongs). Should we separate them for simplicity? Otherwise it looks like there will a lot of issues to be handled as part of a single MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119781332 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Nov 24 16:27:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 24 Nov 2018 15:27:56 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: Ouch, it seems that this gitlab issue is back: https://gitlab.com/gitlab-com/support-forum/issues/1311 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626#note_119782036 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 07:48:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 06:48:02 +0000 Subject: [gnutls-devel] GnuTLS | Minor fixes towards 3.6.5 (!818) References: Message-ID: New Merge Request !818 https://gitlab.com/gnutls/gnutls/merge_requests/818 Branches: tmp-minor-fixes to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Since there seems to be more room for discussion in !808 and !817 needs to wait for tlsfuzzer update, I would like to propose obvious fixes for 3.6.5, currently included in those MRs. ## Checklist * [ ] 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/818 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 11:01:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 10:01:00 +0000 Subject: [gnutls-devel] GnuTLS | READ -1 returned from 0x8, errno=104 gerrno=0 (#622) In-Reply-To: References: Message-ID: Hi, There is not much we can help with that. The error you see is that the peer has closed the connection after seeing the first message in the handshake. You should debug the issue on the server side. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/622#note_119827742 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 11:01:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 10:01:00 +0000 Subject: [gnutls-devel] GnuTLS | READ -1 returned from 0x8, errno=104 gerrno=0 (#622) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #622: https://gitlab.com/gnutls/gnutls/issues/622 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/622 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 11:20:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 10:20:54 +0000 Subject: [gnutls-devel] GnuTLS | READ -1 returned from 0x8, errno=104 gerrno=0 (#622) In-Reply-To: References: Message-ID: I'm closing it for now, but please re-open if there is something you think it is related to gnutls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/622#note_119828609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 12:21:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 11:21:09 +0000 Subject: [gnutls-devel] GnuTLS | Make some tests more portable (!819) References: Message-ID: New Merge Request !819 https://gitlab.com/gnutls/gnutls/merge_requests/819 Project:Branches: rockdaboot/gnutls:tmp-portable-tests to gnutls/gnutls:master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Split out from !809 - these commits should be the "easy to agree on". Once merged, I'll rebase !809. ## Checklist * [ ] 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/819 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 12:26:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 11:26:59 +0000 Subject: [gnutls-devel] GnuTLS | Add CI tarball build (!809) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on .gitlab-ci.yml: > > Debian.cross.aarch64-linux-gnu: > <<: *Debian_cross_template > + > +# Test building from tarball in a non-dev environment > +Tarball: > + stage: stage2-tarball > + image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$ALPINE_BASE_BUILD Just moved most of the commits to !819. I'll rebase this MR (and likely split further) once !819 is merged. The remaining commits are - Alpine CI runner in a second stage - mostly rewritten cipher-api-test.c (not pushed yet, needs some extra discussion) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_119832208 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 12:34:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 11:34:17 +0000 Subject: [gnutls-devel] GnuTLS | tests: resume: suppress compiler warnings (dcf533fd) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/resume.c: > if (t > 0 && params->expect_resume) { > ret = gnutls_session_is_resumed(session); > if (ret == 0) { > - fail("server: session_is_resumed error (%d)\n", t); > + fail("server: session_is_resumed error (%d)\n", (int) t); Why not using %zu instead of casting ? Is there a portability issue with e.g. Windows ? (if yes, there is %zd in lib/nettle/pk.c). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/dcf533fd1ffa17327888101c1f9a573a8937bcc1#note_119833688 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 12:36:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 11:36:42 +0000 Subject: [gnutls-devel] GnuTLS | Minor fixes towards 3.6.5 (!818) In-Reply-To: References: Message-ID: Merge Request !818 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/818 Branches: tmp-minor-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/818 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 12:37:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 11:37:19 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > +} > + > + > int > _gnutls_gen_cert_client_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.client_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the client > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); I have a nice solution that brings us best of both worlds. Hope you like it too. I've created a private inline copy of the function that can be called internally. This private function is then called from the API function. That gives us the optimization that you want and also a function that abstracts the internal data structure away. I think the second benefit of using this function is that it implements logic to retrieve the "ours" and "peers" certificate types. As you mentioned in one of your other comments these modes can be used to optimize some of the code paths for certificate handling. Please take a look at the code and tell me what you think of it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119833840 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 13:32:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 12:32:59 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > + int ret; > + gnutls_pcert_st *apr_cert_list; > + gnutls_privkey_t apr_pkey; > + int apr_cert_list_length; > + > + // Retrieve the appropriate certificate > + if((ret = _gnutls_get_selected_cert(session, &apr_cert_list, > + &apr_cert_list_length, &apr_pkey)) < 0) { > + return gnutls_assert_val(ret); > + } > + > + /* Since we are transmitting a raw public key with no additional > + * certificate credentials attached to it, it doesn't make sense to > + * have more than one certificate set (i.e. to have a certificate chain). > + */ > + if (apr_cert_list_length == 1) { > it would have been simpler to return the error immediately if the list does not equal one Isn't that a matter of coding style? I'm used to check for the condition that I need and then act on that. All other scenario's are then falsy. I find it a good approach, especially within the field of security. What's the advantage of checking the inverse condition and directly returning an error? Just to get rid of the else-statement and one level of indentiation? > why don't you check that the certificate is of RAW type? That is not necessary because this function will only be called when the certificate type is RAWPK. This is tested in `_gnutls_gen_cert_client_crt` and `_gnutls_gen_cert_server_crt`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119837097 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 13:40:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 12:40:09 +0000 Subject: [gnutls-devel] GnuTLS | tests: resume: suppress compiler warnings (dcf533fd) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/resume.c: > if (t > 0 && params->expect_resume) { > ret = gnutls_session_is_resumed(session); > if (ret == 0) { > - fail("server: session_is_resumed error (%d)\n", t); > + fail("server: session_is_resumed error (%d)\n", (int) t); I'm not sure if it is worthwhile; in this context, `t` is always in the range [0,3). Maybe we can simply declare `t` as int. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/dcf533fd1ffa17327888101c1f9a573a8937bcc1#note_119837466 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 15:16:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 14:16:49 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/auth/cert.c: > } > > + > +int _gnutls_proc_rawpk_crt(gnutls_session_t session, > + uint8_t * data, size_t data_size) //REMARK: maybe place this in a different file specific for RawPK? > +{ > + int cert_size, ret; > + cert_auth_info_t info; > + gnutls_pcert_st* peer_certificate; > + gnutls_datum_t tmp_cert; > + > + uint8_t *p = data; // data pointer > + ssize_t dsize = data_size; > + > + // Check whether we've received anything. > + if (data == NULL || data_size == 0) { I've checked the calling code and I think we can safely skip this test because the caller already checks this. I will remove it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119843812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 18:31:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 17:31:11 +0000 Subject: [gnutls-devel] GnuTLS | tests: resume: suppress compiler warnings (dcf533fd) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/resume.c: > if (t > 0 && params->expect_resume) { > ret = gnutls_session_is_resumed(session); > if (ret == 0) { > - fail("server: session_is_resumed error (%d)\n", t); > + fail("server: session_is_resumed error (%d)\n", (int) t); True, that seems to be the best choice. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/dcf533fd1ffa17327888101c1f9a573a8937bcc1#note_119859313 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 18:53:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 17:53:08 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) References: Message-ID: New Merge Request !820 https://gitlab.com/gnutls/gnutls/merge_requests/820 Project:Branches: smuellerDD/gnutls:drbg to gnutls/gnutls:master Author: Stephan Mueller Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. The removal allows the CAVS / ACVP test required for a successful FIPS 140-2 validation to pass. ## Checklist * [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/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Nov 25 22:22:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 25 Nov 2018 21:22:05 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: If I checkout the latest master and try to build it fresh I get the same errors and Make fails. So I'm not sure whether this is a Gitlab problem. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626#note_119887273 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 07:14:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 06:14:50 +0000 Subject: [gnutls-devel] GnuTLS | Minor fixes towards 3.6.5 (!818) 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/818#note_119922969 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 07:34:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 06:34:19 +0000 Subject: [gnutls-devel] GnuTLS | Minor fixes towards 3.6.5 (!818) In-Reply-To: References: Message-ID: Merge Request !818 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/818 Branches: tmp-minor-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/818 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 08:48:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 07:48:11 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: You need to increase the CI run time in your fork at Settings -> CI/CD -> General pipelines. There is a crash though when the library is run on FIPS140 mode, which I could not figure why from the changes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_119961053 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 08:52:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 07:52:45 +0000 Subject: [gnutls-devel] GnuTLS | Make some tests more portable (!819) In-Reply-To: References: Message-ID: Marking it as after next release so that we reduce the risk of a test suite breakage at the release. Let's see it/merge it after 3.6.5 which is this week. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/819#note_119962019 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 12:56:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 11:56:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Fixed the issues. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120044875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 13:03:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 12:03:40 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Actually the failure reason seems to be that `drbg_aes_self_test()` expects the old values. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120047525 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 13:06:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 12:06:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/tpmtool_test.sh: > > +# Kill a process quietly > +# @1: signal, e.g. -9 > +# @2: pid > +kill_quiet() { > + local sig="$1" > + local pid="$2" > + > + sh -c "kill $sig $pid 2>/dev/null" > + return $? > +} > + > +# Terminate a process first using SIGTERM, wait 1s and if still avive use > +# SIGKILL > +# @1: pid > +terminate_proc() { Don't you want to use the fixed function from `scripts/common.sh` !? (Just move kill_quiet over there...) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120048879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:01:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:01:47 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > * then send that one. > */ > if (cred->ncerts == 1 && > - (data_size == 0 || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + (data_size == 0 > + || (session->internals.flags & GNUTLS_FORCE_CLIENT_CERT))) { > + // Do a cert type check > + if (cred->certs[0].cert_list_length > 0 && Since you added that code which adds a public key into the credential structure I think you are in better position to understand the options that it introduces. The best is to check them when adding the public key rather than checking it on every use. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120065848 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:04:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:04:01 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/cert_types.h: > return false; > } > } > + > +/* Checks whether alternative cert types (i.e. other than X.509) > + * are enabled in the application > + */ > +static inline bool _gnutls_are_alternative_cert_types_allowed(gnutls_session_t session) No need to have the `_gnutls_` prefix in inline and static functions. Saves typing and makes code more readable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120066495 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:06:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:06:54 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/gnutls_int.h: > + case GNUTLS_CTYPE_OURS: > + if (IS_SERVER(session)) { > + return session->security_parameters.server_ctype; > + } else { > + return session->security_parameters.client_ctype; > + } > + break; > + case GNUTLS_CTYPE_PEERS: > + if (IS_SERVER(session)) { > + return session->security_parameters.client_ctype; > + } else { > + return session->security_parameters.server_ctype; > + } > + break; > + default: // Illegal parameter passed > + return GNUTLS_E_INVALID_REQUEST; This is not part of `gnutls_certificate_type_t` which this function is returning. If that situation needs to be handled it could return `GNUTLS_CRT_UNKNOWN` which is part of the enumeration. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120067326 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:07:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:07:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > +} > + > + > int > _gnutls_gen_cert_client_crt(gnutls_session_t session, gnutls_buffer_st * data) > { > - switch (session->security_parameters.client_ctype) { > - case GNUTLS_CRT_X509: > - return gen_x509_crt(session, data); > - default: > - gnutls_assert(); > - return GNUTLS_E_INTERNAL_ERROR; > + gnutls_certificate_type_t cert_type; > + > + // Retrieve the (negotiated) certificate type for the client > + cert_type = gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); Seems good to me. btw. no need to use `_gnutls_` prefix for inline static functions. `get_cert_type()` should be sufficient to understand and short enough not to fill the whole line. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120067644 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:15:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:15:38 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > + int ret; > + gnutls_pcert_st *apr_cert_list; > + gnutls_privkey_t apr_pkey; > + int apr_cert_list_length; > + > + // Retrieve the appropriate certificate > + if((ret = _gnutls_get_selected_cert(session, &apr_cert_list, > + &apr_cert_list_length, &apr_pkey)) < 0) { > + return gnutls_assert_val(ret); > + } > + > + /* Since we are transmitting a raw public key with no additional > + * certificate credentials attached to it, it doesn't make sense to > + * have more than one certificate set (i.e. to have a certificate chain). > + */ > + if (apr_cert_list_length == 1) { > Isn't that a matter of coding style? I'm used to check for the condition that I need and then act on that. All other scenario's are then falsy. I find it a good approach, especially within the field of security. What's the advantage of checking the inverse condition and directly returning an error? Just to get rid of the else-statement and one level of indentiation? It is indeed, and it is best to be consistent through the code. Nevertheless we have discussed that in the past, but let me try to demonstrate with an extreme example why eliminating illegal values early makes for more readable code. The first checks for invalid values before and returns early while the other checks for invalid ``` if (vara == 0 || varb == 1 || varc == 2) return -1; /* our error condition */ /* normal code flow */ do_something(); ``` The other approach, is checking within the code flow and does not worry about adding indentation for tests. ``` if (vara == 0) { return -1; } else { if (varb == 1) { return -1; } else { if (varc == 2) return -1; else do_something(); } } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120070133 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:17:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:17:33 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .gitignore: > *.trs > win32 > win64 > +*.orig let's separate this and other cleanups from this patch to make things easy. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120070711 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:20:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:20:14 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/cert_types.h: > switch (cert_type) { > case GNUTLS_CRT_X509: > return 0; > + case GNUTLS_CRT_RAWPK: > + return 2; > default: > return GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE; > } > } > + > +/* Checks whether the given cert type is enabled in the application > + */ > +static inline bool _gnutls_is_cert_type_enabled(gnutls_session_t session, gnutls_certificate_type_t cert_type) Which modules do you mean here? static inline functions are only used in gnutls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120071884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:23:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:23:13 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > + * where > + * length = 3 bytes and > + * certificate = length bytes. > + */ > + ret = _gnutls_buffer_append_data_prefix(data, 24, > + apr_cert_list[0].cert.data, > + apr_cert_list[0].cert.size); > + > + if (ret < 0) return gnutls_assert_val(ret); > + > + return data->length; > + } else { > + /* We found more than one certificate. In that case we don't know > + * which one to send, therefore we send nothing. > + */ > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); // TODO maybe introduce new error type GNUTLS_E_RAWPK_TOO_MANY_KEYS_GIVEN? both options look fine to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120072887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:31:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:31:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > general issues applying to both client and server certificates. The next > section will elaborate on issues arising from client authentication only. > > +In order to use certificate credentials one must first initialize a credentials > +container of type @code{gnutls_certificate_credentials_t}. After use this container must the word container is not used in the manual for structures. Using 'structure' instead of container would make this sentence most consistent with the rest. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120075997 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:34:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:34:22 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > > @showfuncC{gnutls_pcert_import_x509,gnutls_pcert_import_x509_raw,gnutls_pcert_deinit} > > +As of version 3.6.5 GnuTLS supports @ref{Raw public-keys}. With raw public-keys only the I think that raw public keys deserve their own subsection (this is the subsection for certificates) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120076874 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:34:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:34:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > > @showfuncC{gnutls_certificate_set_x509_key_file,gnutls_certificate_set_x509_simple_pkcs12_file,gnutls_certificate_set_retrieve_function2} > > +As of version 3.6.5 GnuTLS supports @ref{Raw public-keys}. With raw public-keys only the Same here about a separate subsection. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120077019 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:36:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:36:10 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > > @showfuncB{gnutls_certificate_verify_peers3,gnutls_certificate_set_verify_function} > > +Note that when using raw public-keys verification will not work because there is no corresponding > +certificate body belonging to the raw key that can be verified. For authenticating raw public-keys Should we say instead of will not work, the exact error code that will be returned in that case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120077541 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:39:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:39:57 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. > CTYPE-CLI-X509 or CTYPE-CLI-X.509, CTYPE-SRV-X509 or CTYPE-SRV-X.509. > +CTYPE-CLI-RAWPK or CTYPE-CLI-RAWPUBKEY, CTYPE-SRV-RAWPK or CTYPE-SRV-RAWPUBKEY. This should explain what these keywords are supposed to do to someone unfamiliar with the code. For example I'd expect to say that CTYPE-X509 enables X509 for both client and server. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120078623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:58:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:58:08 +0000 Subject: [gnutls-devel] GnuTLS | Verify that certtool --outder does not output textual data (#627) References: Message-ID: New Issue was created. Issue 627: https://gitlab.com/gnutls/gnutls/issues/627 Author: Dmitry Eremin-Solenikov Assignee: The following discussion from !810 should be addressed: - [ ] @nmav started a [discussion](https://gitlab.com/gnutls/gnutls/merge_requests/810#note_119258371): (+2 comments) > should we also test here that if output type is DER, no textual data is added? That was a common regression in the past. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 14:58:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 13:58:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/tpmtool_test.sh: > fi > fi > > - # Count how many keys we can create until the TPM locks down due to You also removed this code. Is it intention or accident ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120084592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 15:00:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 14:00:18 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on tests/cert-tests/pkcs7: > fi > done > > +${VALGRIND} "${CERTTOOL}" --inder --p7-info --infile "${srcdir}/data/full.p7b" --outfile "${TMPFILE}" --no-text > +rc=$? > + > +if test "${rc}" != "0"; then > + echo "--no-text pkcs7 info failed 1" > + exit ${rc} > +fi > + > +if ( head -n 1 ${TMPFILE} ; tail -n 1 ${TMPFILE} ) | grep -v -- ----- I have replaced this `grep` command with grep actually checking the tmpfile contents, to verify that it contains only PEM headers and base64-encoded data. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_120085118 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 16:08:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 15:08:23 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/cert_types.h: > switch (cert_type) { > case GNUTLS_CRT_X509: > return 0; > + case GNUTLS_CRT_RAWPK: > + return 2; > default: > return GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE; > } > } > + > +/* Checks whether the given cert type is enabled in the application > + */ > +static inline bool _gnutls_is_cert_type_enabled(gnutls_session_t session, gnutls_certificate_type_t cert_type) With modules I mean compilation units. The current convention is (if I am not mistaken) that if a private library function is called from other units it has the _gnutls_ prefix. If it is local to that unit then we skip the prefix. Since headers are included in several c units these static functions are thus used in several modules. There are other static functions that have the _gnutls_ prefix. That's why I've added the prefix. But you say strip it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120109519 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 16:20:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 15:20:24 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. > CTYPE-CLI-X509 or CTYPE-CLI-X.509, CTYPE-SRV-X509 or CTYPE-SRV-X.509. > +CTYPE-CLI-RAWPK or CTYPE-CLI-RAWPUBKEY, CTYPE-SRV-RAWPK or CTYPE-SRV-RAWPUBKEY. That's true. I had a more elaborate description last time for my previous patch but you asked me to shorten it :P. So do you want me to add the full description now? Or add some kind of table with flags and their meaning? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120118850 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 16:57:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 15:57:24 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/gnutls_int.h: > + case GNUTLS_CTYPE_OURS: > + if (IS_SERVER(session)) { > + return session->security_parameters.server_ctype; > + } else { > + return session->security_parameters.client_ctype; > + } > + break; > + case GNUTLS_CTYPE_PEERS: > + if (IS_SERVER(session)) { > + return session->security_parameters.client_ctype; > + } else { > + return session->security_parameters.server_ctype; > + } > + break; > + default: // Illegal parameter passed > + return GNUTLS_E_INVALID_REQUEST; Good catch. Will fix. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120136837 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 17:11:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 16:11:34 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on tests/tpmtool_test.sh: > > +# Kill a process quietly > +# @1: signal, e.g. -9 > +# @2: pid > +kill_quiet() { > + local sig="$1" > + local pid="$2" > + > + sh -c "kill $sig $pid 2>/dev/null" > + return $? > +} > + > +# Terminate a process first using SIGTERM, wait 1s and if still avive use > +# SIGKILL > +# @1: pid > +terminate_proc() { Yes, it was there. I had made local edits for something else and unfortunately tooks those and pushed them. Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120142151 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 17:11:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 16:11:49 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on tests/tpmtool_test.sh: > fi > fi > > - # Count how many keys we can create until the TPM locks down due to Accident... Removed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120142219 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Nov 26 17:23:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 26 Nov 2018 16:23:42 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: I couldn't find issues in the code. But I don't know if I agree that this behaviour is the best. I mean, if you are trying to add TLS1.3, probably you want to use it. But with this fix, when someone tries to "upgrade" the configuration by adding TLS1.3, he/she can end up with only pre-TLS1.2 protocols enabled. Wouldn't be better to drop TLS1.1/1.0 and keep TLS1.3 instead of the other way around? Or maybe automatically add TLS1.2 when it is missing? I understand that any choice can lead to some confusion when the actual result does not match the expected one, but I would prefer to have a more secure configuration as the final result when such problematic configuration is provided. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815#note_120145760 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 02:18:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 01:18:47 +0000 Subject: [gnutls-devel] GnuTLS | certtool should be able to just emit PEM data without textual annotations above it. (#487) In-Reply-To: References: Message-ID: Reassigned Issue 487 https://gitlab.com/gnutls/gnutls/issues/487 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/487 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:19:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:19:51 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: All discussions on Merge Request !810 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/810 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:20:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:20:02 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Merge Request !810 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/810 Project:Branches: GostCrypt/gnutls:pem-notext to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:21:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:21:46 +0000 Subject: [gnutls-devel] GnuTLS | Verify that certtool --outder does not output textual data (#627) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:29:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:29:36 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: Indeed there are two issues here. 1. gitlab doesn't indicate a compilation error 2. The code here is using unconditionally CKM_EDDSA The last is within our control to fix. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626#note_120326989 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:29:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:29:40 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:34:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:34:52 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: > I couldn't find issues in the code. But I don't know if I agree that this behaviour is the best. I mean, if you are trying to add TLS1.3, probably you want to use it. But with this fix, when someone tries to "upgrade" the configuration by adding TLS1.3, he/she can end up with only pre-TLS1.2 protocols enabled. Indeed, this code is about applications which use something like "NORMAL:-VERS-TLS1.2" and expect to have TLS1.0 and TLS1.1 enabled. After the upgrade to a TLS1.3 supporting version this code will enable TLS1.3 in addition to TLS1.1 and TLS1.0 (that's what this wine app was doing). > Wouldn't be better to drop TLS1.1/1.0 and keep TLS1.3 instead of the other way around? Or maybe automatically add TLS1.2 when it is missing? In that particular case the application was specifically requesting for TLS1.1 and TLS1.0 thus disabling them and only allowing TLS1.3 would have been the wrong thing to do, in terms of what the application intended, and in practice as its server did not support TLS1.3. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815#note_120328623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:35:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:35:17 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: Reassigned Merge Request 815 https://gitlab.com/gnutls/gnutls/merge_requests/815 Assignee changed to Anderson Sasaki -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:35:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:35:30 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 10:51:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 09:51:24 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: This one is "In process of being merged" for the last 30 minutes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_120338233 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 11:45:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 10:45:13 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: > In that particular case the application was specifically requesting for TLS1.1 and TLS1.0 thus disabling them and only allowing TLS1.3 would have been the wrong thing to do, in terms of what the application intended, and in practice as its server did not support TLS1.3. Ok, I think I understood better the problematic scenario. It is about TLS1.3 being unexpectedly enabled by default after upgrading gnutls. So the expected behaviour, by this application point of view, is to disable any version >TLS1.2 when using "NORMAL:-VERS-TLS1.2", for example. Anyway, thinking better, I agree that it is not that bad to require TLS1.2 to be enabled together with TLS1.3 because this is enforced only when TLS1.0/1.1 are enabled. So, Approved. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815#note_120358350 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 11:45:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 10:45:16 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: Merge Request !815 was approved by Anderson Sasaki Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/815 Branches: tmp-tls10-tls13-fix to master Author: Nikos Mavrogiannopoulos Assignee: Anderson Sasaki -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 11:59:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 10:59:06 +0000 Subject: [gnutls-devel] GnuTLS | certtool should be able to just emit PEM data without textual annotations above it. (#487) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #487: https://gitlab.com/gnutls/gnutls/issues/487 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/487 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 11:59:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 10:59:10 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: Merge Request !810 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/810 Project:Branches: GostCrypt/gnutls:pem-notext to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 12:40:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 11:40:13 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/tpmtool_test.sh: > fi > fi > > - # Count how many keys we can create until the TPM locks down due to What I meant is that you removed a block of code, but you gave no hint about it. So if you say 'Accident', don't you want to add it again ? I'm sorry, but I just don't understand what your intention is. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120378026 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 12:57:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 11:57:16 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: It needed some time to be absorbed :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_120382962 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:04:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:04:17 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Stefan Berger commented on a discussion on tests/tpmtool_test.sh: > fi > fi > > - # Count how many keys we can create until the TPM locks down due to Sorry. It was an accident to have that code there. I would add this part back again later, if at all. For now this is only about synchronizing the stopping of the processes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120385179 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:08:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:08:26 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > #endif > /* Get time_t. */ > #include > +/* Get uint*_t. */ > +#include Our API doesn't require the `uint*_t` so far; we can certainly consider that but we shouldn't introduce as part of this commit or MR. We use `unsigned char` for `uint8_t`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120386266 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:10:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:10:23 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_CLIENT: Connection end is a client. > * @GNUTLS_DATAGRAM: Connection is datagram oriented (DTLS). Since 3.0.0. > * @GNUTLS_NONBLOCK: Connection should not block. Since 3.0.0. > - * @GNUTLS_NO_SIGNAL: In systems where SIGPIPE is delivered on send, it will be disabled. That flag has effect in systems which support the MSG_NOSIGNAL sockets flag (since 3.4.2). > - * @GNUTLS_NO_EXTENSIONS: Do not enable any TLS extensions by default (since 3.1.2). As TLS 1.2 and later require extensions this option is considered obsolete and should not be used. > - * @GNUTLS_NO_REPLAY_PROTECTION: Disable any replay protection in DTLS. This must only be used if replay protection is achieved using other means. Since 3.2.2. > - * @GNUTLS_ALLOW_ID_CHANGE: Allow the peer to replace its certificate, or change its ID during a rehandshake. This change is often used in attacks and thus prohibited by default. Since 3.5.0. > - * @GNUTLS_ENABLE_FALSE_START: Enable the TLS false start on client side if the negotiated ciphersuites allow it. This will enable sending data prior to the handshake being complete, and may introduce a risk of crypto failure when combined with certain key exchanged; for that GnuTLS may not enable that option in ciphersuites that are known to be not safe for false start. Since 3.5.0. > - * @GNUTLS_ENABLE_EARLY_START: Under TLS1.3 allow the server to return earlier than the full handshake > - * finish; similarly to false start the handshake will be completed once data are received by the > - * client, while the server is able to transmit sooner. This is not enabled by default as it could > - * break certain existing server assumptions and use-cases. Since 3.6.4. > - * @GNUTLS_ENABLE_EARLY_DATA: Under TLS1.3 allow the server to receive early data sent as part of the initial ClientHello (0-RTT). This is not enabled by default as early data has weaker security properties than other data. Since 3.6.5. > - * @GNUTLS_FORCE_CLIENT_CERT: When in client side and only a single cert is specified, send that certificate irrespective of the issuers expected by the server. Since 3.5.0. > + * @GNUTLS_NO_EXTENSIONS: Do not enable any TLS extensions by default (since 3.1.2). As TLS 1.2 and Why this large change? Such unrelated changes make the review of this commit, a very tedious task. Please limit to the changes related to this feature. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120386733 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:11:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:11:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_POST_HANDSHAKE_AUTH: Enable post handshake authentication for server and client. When set and > * a server requests authentication after handshake %GNUTLS_E_REAUTH_REQUEST will be returned > * by gnutls_record_recv(). A client should then call gnutls_reauth() to re-authenticate. > + * @GNUTLS_NO_AUTO_REKEY: Disable auto-rekeying under TLS1.3. If this option is not specified > + * gnutls will force a rekey after 2^24 records have been sent. > * @GNUTLS_SAFE_PADDING_CHECK: Flag to indicate that the TLS 1.3 padding check will be done in a > * safe way which doesn't leak the pad size based on GnuTLS processing time. This is of use to > * applications which hide the length of transferred data via the TLS1.3 padding mechanism and > * are already taking steps to hide the data processing time. This comes at a performance > * penalty. > - * @GNUTLS_ENABLE_CERT_TYPE_NEG: Enable certificate type negotiation extensions (RFC7250). > + * @GNUTLS_ENABLE_EARLY_START: Under TLS1.3 allow the server to return earlier than the full handshake > + * finish; similarly to false start the handshake will be completed once data are received by the > + * client, while the server is able to transmit sooner. This is not enabled by default as it could > + * break certain existing server assumptions and use-cases. Since 3.6.4. > + * @GNUTLS_ENABLE_RAWPK: Enables raw public-key credentials to be used during the handshaked. Since 3.6.5. Maybe: 'allows raw public keys to be negotiated during the handshake.' (note also the typo in 'handshaked') -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120387144 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:14:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:14:12 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > + const char **names, > + uint16_t names_length, > + unsigned int flags); > + > +int gnutls_certificate_set_rawpk_key_file(gnutls_certificate_credentials_t cred, > + const char* rawpkfile, > + const char* privkeyfile, > + gnutls_x509_crt_fmt_t format, > + const char *pass, > + unsigned int key_usage, > + const char **names, > + uint16_t names_length, > + unsigned int flags); > + > +int gnutls_certificate_get_rawpk_keypair(gnutls_certificate_credentials_t cred, > + unsigned index, index is also a function name in `strings.h`, if you try to access a variable called index with strings included, this may confuse the compiler. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120387738 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:17:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:17:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + * representation and copy it into our pcert. It is this raw data > + * that will be transfered to the peer via a Certificate msg. > + * According to the spec (RFC7250) a DER representation must be used. > + */ > + ret = gnutls_pubkey_export2(pubkey, GNUTLS_X509_FMT_DER, &pcert->cert); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Set the pubkey to the one passed to this function > + pcert->pubkey = pubkey; > + > + // Set the certificate type to Raw Public Key > + pcert->type = GNUTLS_CRT_RAWPK; > + > + // All OK unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120388709 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:17:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:17:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + > + /* A pcert struct holds a raw copy of the certificate data. > + * Therefore we convert our gnutls_pubkey_t to its raw DER > + * representation and copy it into our pcert. It is this raw data > + * that will be transfered to the peer via a Certificate msg. > + * According to the spec (RFC7250) a DER representation must be used. > + */ > + ret = gnutls_pubkey_export2(pubkey, GNUTLS_X509_FMT_DER, &pcert->cert); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Set the pubkey to the one passed to this function > + pcert->pubkey = pubkey; > + > + // Set the certificate type to Raw Public Key unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120388735 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:17:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:17:47 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + } > + > + memset(pcert, 0, sizeof(*pcert)); > + > + /* A pcert struct holds a raw copy of the certificate data. > + * Therefore we convert our gnutls_pubkey_t to its raw DER > + * representation and copy it into our pcert. It is this raw data > + * that will be transfered to the peer via a Certificate msg. > + * According to the spec (RFC7250) a DER representation must be used. > + */ > + ret = gnutls_pubkey_export2(pubkey, GNUTLS_X509_FMT_DER, &pcert->cert); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Set the pubkey to the one passed to this function unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120388776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:20:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:20:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + if (pubkey == NULL) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + memset(pcert, 0, sizeof(*pcert)); > + > + /* A pcert struct holds a raw copy of the certificate data. > + * Therefore we convert our gnutls_pubkey_t to its raw DER Not sure if we need both the comments above and this one. I am not sure what is the value of this text here as comment vs adding all information we need to document in the function documentation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120389564 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:22:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:22:32 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a > + * negative error value. > + * > + * Since: 3.6.5 > + **/ > +int gnutls_pcert_import_rawpk_raw(gnutls_pcert_st* pcert, > + const gnutls_datum_t* rawpubkey, > + gnutls_x509_crt_fmt_t format, > + unsigned int key_usage, unsigned int flags) > +{ > + int ret; > + > + // Check whether a valid pointer to a rawpubkey is passed unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120390129 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:22:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:22:38 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + * > + * Since: 3.6.5 > + **/ > +int gnutls_pcert_import_rawpk_raw(gnutls_pcert_st* pcert, > + const gnutls_datum_t* rawpubkey, > + gnutls_x509_crt_fmt_t format, > + unsigned int key_usage, unsigned int flags) > +{ > + int ret; > + > + // Check whether a valid pointer to a rawpubkey is passed > + if (rawpubkey == NULL) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + // Reset our pcert memory to all zeros unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120390154 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:22:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:22:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > +int gnutls_pcert_import_rawpk_raw(gnutls_pcert_st* pcert, > + const gnutls_datum_t* rawpubkey, > + gnutls_x509_crt_fmt_t format, > + unsigned int key_usage, unsigned int flags) > +{ > + int ret; > + > + // Check whether a valid pointer to a rawpubkey is passed > + if (rawpubkey == NULL) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + // Reset our pcert memory to all zeros > + memset(pcert, 0, sizeof(*pcert)); > + > + // Initialize our public key structure unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120390231 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:23:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:23:10 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + // Reset our pcert memory to all zeros > + memset(pcert, 0, sizeof(*pcert)); > + > + // Initialize our public key structure > + ret = gnutls_pubkey_init(&pcert->pubkey); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Convert our raw public-key to a gnutls_pubkey_t structure > + ret = gnutls_pubkey_import(pcert->pubkey, rawpubkey, format); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Set key usage bits. This is normally defined in the certificate unnecessary comment; that info is present in the function documentation -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120390355 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:24:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:24:24 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + pcert->pubkey->key_usage = key_usage; > + > + /* A pcert struct holds a raw copy of the certificate data. > + * It is this raw data that will be transfered to the peer via a > + * Certificate message. According to the spec (RFC7250) a DER > + * representation must be used. Therefore we check the format and > + * convert if necessary. > + */ > + if (format == GNUTLS_X509_FMT_PEM) { > + // Decode the PEM format to DER and copy to our pcert > + ret = _gnutls_fbase64_decode(PEM_PK, > + rawpubkey->data, rawpubkey->size, > + &pcert->cert); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); memory leak -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120391227 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:24:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:24:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + ret = gnutls_pubkey_import(pcert->pubkey, rawpubkey, format); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // Set key usage bits. This is normally defined in the certificate > + pcert->pubkey->key_usage = key_usage; > + > + /* A pcert struct holds a raw copy of the certificate data. > + * It is this raw data that will be transfered to the peer via a > + * Certificate message. According to the spec (RFC7250) a DER > + * representation must be used. Therefore we check the format and > + * convert if necessary. > + */ > + if (format == GNUTLS_X509_FMT_PEM) { > + // Decode the PEM format to DER and copy to our pcert unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120391345 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:25:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:25:18 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + */ > + if (format == GNUTLS_X509_FMT_PEM) { > + // Decode the PEM format to DER and copy to our pcert > + ret = _gnutls_fbase64_decode(PEM_PK, > + rawpubkey->data, rawpubkey->size, > + &pcert->cert); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + } else { > + // Directly copy the raw DER data to our pcert > + ret = _gnutls_set_datum(&pcert->cert, rawpubkey->data, rawpubkey->size); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); memory leak; the pubkey in pcert -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120391503 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:25:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:25:25 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + } else { > + // Directly copy the raw DER data to our pcert > + ret = _gnutls_set_datum(&pcert->cert, rawpubkey->data, rawpubkey->size); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + } > + > + // Set the certificate type to Raw Public Key > + pcert->type = GNUTLS_CRT_RAWPK; > + > + // All OK unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120391526 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:25:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:25:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pcert.c: > + rawpubkey->data, rawpubkey->size, > + &pcert->cert); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + } else { > + // Directly copy the raw DER data to our pcert > + ret = _gnutls_set_datum(&pcert->cert, rawpubkey->data, rawpubkey->size); > + > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + } > + > + // Set the certificate type to Raw Public Key unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120391547 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:31:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:31:12 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/session.c: > - gnutls_certificate_type_get_name(ctype_client)); > - } else { > - // print proto version, client cert type, server cert type > - snprintf(proto_name, sizeof(proto_name), "%s-%s-%s", > - gnutls_protocol_get_name(get_num_version(session)), > - gnutls_certificate_type_get_name(ctype_client), > - gnutls_certificate_type_get_name(ctype_server)); > - } > - } else { // Assumed default certificate type (X.509) > - snprintf(proto_name, sizeof(proto_name), "%s", > - gnutls_protocol_get_name(get_num_version > - (session))); > + // Get certificate types > + ctype_client = _gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > + ctype_server = _gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > + This code is not equivalent to what it replaces. It always adds the certificate type, although that's not what the previous code does. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120393001 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 13:50:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 12:50:23 +0000 Subject: [gnutls-devel] GnuTLS | Fix session description info printing (!821) References: Message-ID: New Merge Request !821 https://gitlab.com/gnutls/gnutls/merge_requests/821 Branches: tmp-fix-cs-description to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This fixes a truncation issue in session description information printing for certain ciphersuites, and adds a limited testing of expected description strings for certain ciphersuites. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:01:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:01:14 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on NEWS: > > ** Improved counter-measures for TLS CBC record padding. Kenny Paterson, Eyal Ronen > and Adi Shamir reported that the existing counter-measures had certain issues and > - were insufficient when the attacker has additional access to the CPU cache and > + were insufficient when the attacker has additional access to the CPU cache and Unrelated changes to past entries -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120402545 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:02:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:02:15 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth.c: > } > > > -/* > +/* unrelated change to this MR -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120403048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:02:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:02:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/publickey.c: > .curve = GNUTLS_ECC_CURVE_INVALID }, > { .name = "ECDH (X25519)", .oid = "1.3.101.110", .id = GNUTLS_PK_ECDH_X25519, > .curve = GNUTLS_ECC_CURVE_X25519 }, > - { .name = "UNKNOWN", .oid = NULL, .id = GNUTLS_PK_UNKNOWN, > + { .name = "UNKNOWN", .oid = NULL, .id = GNUTLS_PK_UNKNOWN, unrelated change this MR; there no other changes to that file -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120403305 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:06:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:06:20 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS error: A packet with illegal or unsupported version was received. (#621) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #621: https://gitlab.com/gnutls/gnutls/issues/621 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/621 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:06:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:06:22 +0000 Subject: [gnutls-devel] GnuTLS | Prevent applications from combining legacy versions of TLS with TLS1.3 (!815) In-Reply-To: References: Message-ID: Merge Request !815 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/815 Branches: tmp-tls10-tls13-fix to master Author: Nikos Mavrogiannopoulos Assignee: Anderson Sasaki -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/815 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:07:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:07:16 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + */ > + DECR_LEN(dsize, 3); > + cert_size = _gnutls_read_uint24(p); > + p += 3; > + > + /* Ensure no discrepancy in data */ > + if (cert_size != dsize) > + return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH); > + > + > + if (cert_size == 0) { > + // No certificate was sent. This is not OK. > + return gnutls_assert_val(GNUTLS_E_NO_CERTIFICATE_FOUND); > + } > + > + // Check the rest of our packet length unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405100 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:07:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:07:32 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + if (cert_size != dsize) > + return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH); > + > + > + if (cert_size == 0) { > + // No certificate was sent. This is not OK. > + return gnutls_assert_val(GNUTLS_E_NO_CERTIFICATE_FOUND); > + } > + > + // Check the rest of our packet length > + DECR_LEN_FINAL(dsize, cert_size); > + > + /* We are now going to read our certificate and store it into > + * the authentication info structure. > + */ > + // First create a tmp datum with our certificate unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405176 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:07:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:07:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + if (cert_size == 0) { > + // No certificate was sent. This is not OK. > + return gnutls_assert_val(GNUTLS_E_NO_CERTIFICATE_FOUND); > + } > + > + // Check the rest of our packet length > + DECR_LEN_FINAL(dsize, cert_size); > + > + /* We are now going to read our certificate and store it into > + * the authentication info structure. > + */ > + // First create a tmp datum with our certificate > + tmp_cert.size = cert_size; > + tmp_cert.data = p; > + > + // Allocate memory for our pcert unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405212 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:08:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:08:07 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + > + // Import our raw certificate holding only a raw public key into this pcert > + ret = gnutls_pcert_import_rawpk_raw(peer_certificate, &tmp_cert, GNUTLS_X509_FMT_DER, 0, 0); > + if (ret < 0) { > + gnutls_assert(); > + goto cleanup; > + } > + > + // Check whether the PK algo is compatible with the negotiated KX > + ret = check_pk_compat(session, peer_certificate->pubkey); > + if (ret < 0) { > + gnutls_assert(); > + goto cleanup; > + } > + > + // Prepare our authentication info structures unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405324 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:08:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:08:14 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + // Check whether the PK algo is compatible with the negotiated KX > + ret = check_pk_compat(session, peer_certificate->pubkey); > + if (ret < 0) { > + gnutls_assert(); > + goto cleanup; > + } > + > + // Prepare our authentication info structures > + ret = _gnutls_auth_info_init(session, GNUTLS_CRD_CERTIFICATE, > + sizeof(cert_auth_info_st), 1); > + if (ret < 0) { > + gnutls_assert(); > + goto cleanup; > + } > + > + // Retrieve the structure that holds the peer's authentication data unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405368 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:08:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:08:22 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/cert.c: > + goto cleanup; > + } > + > + // Retrieve the structure that holds the peer's authentication data > + info = _gnutls_get_auth_info(session, GNUTLS_CRD_CERTIFICATE); > + > + /* Copy our imported certificate into the auth info structure > + * and free our temporary cert storage peer_certificate. > + */ > + ret = _gnutls_pcert_to_auth_info(info, peer_certificate, 1); > + if (ret < 0) { > + gnutls_assert(); > + goto cleanup; > + } > + > + // Everything is okay unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120405409 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:12:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:12:01 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + */ > + > +#include "gnutls_int.h" > +#include > +#include "datum.h" > +#include "auth/cert.h" > +#include "x509.h" > +#include "cert-cred.h" > +#include "read-file.h" > +#include > + > + > +/** > + * gnutls_certificate_set_rawpk_key_mem: > + * @cred: is a #gnutls_certificate_credentials_t type. > + * @subject_public_key_info: contains a raw public key in nit: that's quite long for variable name could be abbreviated to 'spki'; the full name can be spelled out in the description. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120406426 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:13:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:13:15 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * @cred: is a #gnutls_certificate_credentials_t type. > + * @subject_public_key_info: contains a raw public key in > + * PKIX.SubjectPublicKeyInfo format. > + * @pkey: contains a raw private key. > + * @format: encoding of the keys. DER or PEM. > + * @pass: an optional password to unlock the private key pkey. > + * @key_usage: An ORed sequence of %GNUTLS_KEY_* flags. > + * @names: is an array of DNS names belonging to the public-key (NULL if none). > + * @names_length: holds the length of the names list. > + * @flags: an ORed sequence of #gnutls_pkcs_encrypt_flags_t. > + * These apply to the private key pkey. > + * > + * This function sets a public/private keypair in the > + * #gnutls_certificate_credentials_t type to be used for authentication > + * and/or encryption. @subject_public_key_info and @privkey should match > + * otherwise set signatures cannot be validated. This function should The text about matching is incorrect. If they key/pubkey pair don't match this function will fail with a specific error code. If we are to mention about this, it should be below, when we document the error codes returned. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120406752 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:15:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:15:23 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * #gnutls_certificate_credentials_t type to be used for authentication > + * and/or encryption. @subject_public_key_info and @privkey should match > + * otherwise set signatures cannot be validated. This function should > + * be called once for the client because there is currently no mechanism > + * to determine which raw public-key to select for the peer when there > + * are multiple present. Multiple raw public keys for the server can be > + * distinghuished by setting the @names. > + * > + * Note here that @subject_public_key_info is a raw public-key as defined > + * in RFC7250. It means that there is no surrounding certificate that > + * holds the public key and that there is therefore no direct mechanism > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, Is that correct? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120407316 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:18:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:18:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, > + * and the openssl format and will be autodetected. > + * > + * If the raw public-key and the private key are given in PEM encoding > + * then the strings that hold their values must be null terminated. > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Note that, this function by default returns zero on success and a > + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2 Given that this is a new API, why not return the v2 api version return code by default? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120408294 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:35:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:35:33 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_CLIENT: Connection end is a client. > * @GNUTLS_DATAGRAM: Connection is datagram oriented (DTLS). Since 3.0.0. > * @GNUTLS_NONBLOCK: Connection should not block. Since 3.0.0. > - * @GNUTLS_NO_SIGNAL: In systems where SIGPIPE is delivered on send, it will be disabled. That flag has effect in systems which support the MSG_NOSIGNAL sockets flag (since 3.4.2). > - * @GNUTLS_NO_EXTENSIONS: Do not enable any TLS extensions by default (since 3.1.2). As TLS 1.2 and later require extensions this option is considered obsolete and should not be used. > - * @GNUTLS_NO_REPLAY_PROTECTION: Disable any replay protection in DTLS. This must only be used if replay protection is achieved using other means. Since 3.2.2. > - * @GNUTLS_ALLOW_ID_CHANGE: Allow the peer to replace its certificate, or change its ID during a rehandshake. This change is often used in attacks and thus prohibited by default. Since 3.5.0. > - * @GNUTLS_ENABLE_FALSE_START: Enable the TLS false start on client side if the negotiated ciphersuites allow it. This will enable sending data prior to the handshake being complete, and may introduce a risk of crypto failure when combined with certain key exchanged; for that GnuTLS may not enable that option in ciphersuites that are known to be not safe for false start. Since 3.5.0. > - * @GNUTLS_ENABLE_EARLY_START: Under TLS1.3 allow the server to return earlier than the full handshake > - * finish; similarly to false start the handshake will be completed once data are received by the > - * client, while the server is able to transmit sooner. This is not enabled by default as it could > - * break certain existing server assumptions and use-cases. Since 3.6.4. > - * @GNUTLS_ENABLE_EARLY_DATA: Under TLS1.3 allow the server to receive early data sent as part of the initial ClientHello (0-RTT). This is not enabled by default as early data has weaker security properties than other data. Since 3.6.5. > - * @GNUTLS_FORCE_CLIENT_CERT: When in client side and only a single cert is specified, send that certificate irrespective of the issuers expected by the server. Since 3.5.0. > + * @GNUTLS_NO_EXTENSIONS: Do not enable any TLS extensions by default (since 3.1.2). As TLS 1.2 and I reordered the comments to match the actual flags. Do you want me to change it back? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120416465 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:36:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:36:44 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > + const char **names, > + uint16_t names_length, > + unsigned int flags); > + > +int gnutls_certificate_set_rawpk_key_file(gnutls_certificate_credentials_t cred, > + const char* rawpkfile, > + const char* privkeyfile, > + gnutls_x509_crt_fmt_t format, > + const char *pass, > + unsigned int key_usage, > + const char **names, > + uint16_t names_length, > + unsigned int flags); > + > +int gnutls_certificate_get_rawpk_keypair(gnutls_certificate_credentials_t cred, > + unsigned index, Good to know. I will update it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120417001 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:41:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:41:36 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, > + * and the openssl format and will be autodetected. > + * > + * If the raw public-key and the private key are given in PEM encoding > + * then the strings that hold their values must be null terminated. > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Note that, this function by default returns zero on success and a > + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2 We could do that but users can not get the old behaviour back. Is that what we want? I think it is consistent with all other API functions to return an error code. Only the certificate setters deviate from that by optionally returning an index. Do we really want to change the default behaviour? I would say, let users decide by setting the API flag. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120418944 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:45:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:45:10 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + > + // A complete key pair must be given > + if (pkey == NULL || subject_public_key_info == NULL) { > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + } > + > + /* Import our private key. This function does all the necessary > + * inits, checks and imports. */ > + ret = _gnutls_read_key_mem(cred, pkey->data, pkey->size, > + format, pass, flags, &privkey); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + /* We now convert our raw public key to a parsed certificate (pcert) structure */ > + // Allocate some memory unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120419957 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 14:45:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 13:45:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + const gnutls_datum_t* subject_public_key_info, > + const gnutls_datum_t* pkey, > + gnutls_x509_crt_fmt_t format, > + const char* pass, > + unsigned int key_usage, > + const char **names, > + uint16_t names_length, > + unsigned int flags) > +{ > + int ret; > + gnutls_privkey_t privkey; > + gnutls_pcert_st* pcert; > + gnutls_str_array_t str_names; > + uint16_t i; > + > + // A complete key pair must be given unnecessary comment; if that's necessary to document I think the place is on the function description -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120420183 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:01:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:01:12 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Merge Request !814 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/814 Project:Branches: stefanberger/gnutls:tpm12_extend_testcase to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:04:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:04:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: All discussions on Merge Request !814 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/814 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:05:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:05:02 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Merge Request !814 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/814 Project:Branches: stefanberger/gnutls:tpm12_extend_testcase to gnutls/gnutls:master Author: Stefan Berger Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:05:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:05:42 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: Thanks for your work ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120429741 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:35:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:35:59 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + gnutls_free(pcert); > + > + return gnutls_assert_val(ret); > + } > + // Successfully added a certificate > + cred->ncerts++; > + > + /* Check whether the key pair matches. > + * After this point we do not deinitialize anything on failure to avoid > + * double freeing. We intentionally keep everything as the credentials state > + * is documented to be in undefined state. */ > + if ((ret = _gnutls_check_key_cert_match(cred)) < 0) { > + return gnutls_assert_val(ret); > + } > + > + // OK, all fine unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120440193 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:44:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:44:58 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * #gnutls_certificate_credentials_t type to be used for authentication > + * and/or encryption. @subject_public_key_info and @privkey should match > + * otherwise set signatures cannot be validated. This function should > + * be called once for the client because there is currently no mechanism > + * to determine which raw public-key to select for the peer when there > + * are multiple present. Multiple raw public keys for the server can be > + * distinghuished by setting the @names. > + * > + * Note here that @subject_public_key_info is a raw public-key as defined > + * in RFC7250. It means that there is no surrounding certificate that > + * holds the public key and that there is therefore no direct mechanism > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, If the PKCS#12 or PKCS#8 file have the necessary parameters to determine the public key, would I need to specify a separate public key? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120442991 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:47:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:47:09 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, > + * and the openssl format and will be autodetected. > + * > + * If the raw public-key and the private key are given in PEM encoding > + * then the strings that hold their values must be null terminated. > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Note that, this function by default returns zero on success and a > + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2 I am not sure. The goal for V2 was not to provide an option to the caller, but to prevent callers which assumed that zero is the returned value not to break. That is it was a necessary change to maintain backwards compatibility. We have no requirement to have this API backwards compatible because it is a new one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120443655 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:47:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:47:45 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + gnutls_x509_crt_fmt_t format, > + const char *pass, > + unsigned int key_usage, > + const char **names, > + uint16_t names_length, > + unsigned int flags) > +{ > + int ret; > + gnutls_privkey_t privkey; > + gnutls_pcert_st* pcert; > + gnutls_datum_t rawpubkey = { NULL, 0 }; // to hold rawpk data from file > + size_t key_size; > + gnutls_str_array_t str_names; > + uint16_t i; > + > + // A complete key pair must be given unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120443837 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:50:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:50:20 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + > + // A complete key pair must be given > + if (rawpkfile == NULL || privkeyfile == NULL) { > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + } > + > + /* Import our private key. This function does all the necessary > + * inits, checks and imports. */ > + ret = _gnutls_read_key_file(cred, privkeyfile, format, pass, flags, &privkey); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // TODO FUTURE: support URLs > + if (gnutls_url_is_supported(rawpkfile)) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); Ouch, that's a serious limitation. Why is that? We already have `gnutls_pubkey_import_url` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120445149 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:50:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:50:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + // TODO FUTURE: support URLs > + if (gnutls_url_is_supported(rawpkfile)) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + /* Read our raw public-key into memory */ > + rawpubkey.data = (void*) read_binary_file(rawpkfile, &key_size); > + if (rawpubkey.data == NULL) { > + return gnutls_assert_val(GNUTLS_E_FILE_ERROR); > + } > + rawpubkey.size = key_size; // Implicit type casting > + > + /* We now convert our raw public key that we've loaded into memory to > + * a parsed certificate (pcert) structure > + */ > + // Allocate some memory unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120445321 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:51:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:51:06 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + return gnutls_assert_val(GNUTLS_E_FILE_ERROR); > + } > + rawpubkey.size = key_size; // Implicit type casting > + > + /* We now convert our raw public key that we've loaded into memory to > + * a parsed certificate (pcert) structure > + */ > + // Allocate some memory > + pcert = gnutls_calloc(1, sizeof(*pcert)); > + if (pcert == NULL) { > + gnutls_privkey_deinit(privkey); > + _gnutls_free_datum(&rawpubkey); > + > + return gnutls_assert_val(GNUTLS_E_MEMORY_ERROR); > + } > + // Import our raw public key to the pcert structure unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120445490 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:51:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:51:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + gnutls_free(pcert); > + > + return gnutls_assert_val(ret); > + } > + // Successfully added a certificate > + cred->ncerts++; > + > + /* Check whether the key pair matches. > + * After this point we do not deinitialize anything on failure to avoid > + * double freeing. We intentionally keep everything as the credentials state > + * is documented to be in undefined state. */ > + if ((ret = _gnutls_check_key_cert_match(cred)) < 0) { > + return gnutls_assert_val(ret); > + } > + > + // OK, all fine unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120445674 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:52:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:52:11 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST > + * is returned. > + * > + * Returns: %GNUTLS_E_SUCCESS (0) on success, or a negative error code. > + * > + * Since: 3.6.5 > + */ > +int > +gnutls_certificate_get_rawpk_keypair(gnutls_certificate_credentials_t cred, > + unsigned index, > + gnutls_pubkey_t* subject_public_key_info, > + gnutls_privkey_t* privkey) > +{ > + // Check whether the request is in range of what we have stored unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120445924 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 15:55:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 14:55:56 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST Shouldn't this be made the behavior of the equivalent X.509 certification functions as well? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120447187 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:00:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:00:30 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:05:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:05:26 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/cert_types.h: > + return true; > + case GNUTLS_CRT_RAWPK: > + return session->internals.flags & GNUTLS_ENABLE_RAWPK; > + default: > + // When not explicitly supported here disable it > + return false; > + } > +} > + > +/* Checks whether alternative cert types (i.e. other than X.509) > + * are enabled in the application > + */ > +static inline bool _gnutls_are_alternative_cert_types_allowed(gnutls_session_t session) > +{ > + // OR-ed list of defined cert type init flags > + uint64_t cert_types_flags = GNUTLS_ENABLE_RAWPK; I do not think there can be a compiler which will generate inefficient code, though I have seen such cases. The `uint64_t` is unnecessary, though I think using a define here would be more efficient. e.g., ``` #define ALL_CERT_TYPES GNUTLS_ENABLE_RAWPK ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120450201 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:06:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:06:35 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/client_cert_type.c: > * when we cannot find a matching client certificate. This is conform > * spec (RFC7250, 4.2 case 2.). > */ > - cert_type = > - _gnutls_cert_type2IANA(session-> > - security_parameters.client_ctype); > + ret = _gnutls_cert_type2IANA(_gnutls_certificate_type_get2( > + session, GNUTLS_CTYPE_CLIENT)); > + > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + cert_type = ret; // For readability > > + // Add cert type to msg buffer unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120450575 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:07:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:07:03 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/server_cert_type.c: > } > } else { // Server mode > // Retrieve negotiated server certificate type and send it > - cert_type = > - _gnutls_cert_type2IANA(session->security_parameters. > - server_ctype); > + ret = _gnutls_cert_type2IANA(_gnutls_certificate_type_get2( > + session, GNUTLS_CTYPE_SERVER)); > + > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + cert_type = ret; // For readability > > + // Add cert type to msg buffer unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120450734 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:07:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:07:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/gnutls_int.h: > + case GNUTLS_CTYPE_OURS: > + if (IS_SERVER(session)) { > + return session->security_parameters.server_ctype; > + } else { > + return session->security_parameters.client_ctype; > + } > + break; > + case GNUTLS_CTYPE_PEERS: > + if (IS_SERVER(session)) { > + return session->security_parameters.client_ctype; > + } else { > + return session->security_parameters.server_ctype; > + } > + break; > + default: // Illegal parameter passed > + return GNUTLS_E_INVALID_REQUEST; The error code is not in the set that this function is expected to return -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120450992 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:10:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:10:49 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/cert_types.h: > switch (cert_type) { > case GNUTLS_CRT_X509: > return 0; > + case GNUTLS_CRT_RAWPK: > + return 2; > default: > return GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE; > } > } > + > +/* Checks whether the given cert type is enabled in the application > + */ > +static inline bool _gnutls_is_cert_type_enabled(gnutls_session_t session, gnutls_certificate_type_t cert_type) Yes, I think it makes them simpler to read/use. We can treat static/inline functions with the prefix as a old relic to eventually remove. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120451863 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:15:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:15:28 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/verify-tofu.c: > + pubkey.data = cert->data; > + pubkey.size = cert->size; > + need_free = false; > + break; > + default: > + return gnutls_assert_val(GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE); > } > > + // Verify our pubkey against the database > ret = tdb->verify(db_name, host, service, &pubkey); > if (ret < 0 && ret != GNUTLS_E_CERTIFICATE_KEY_MISMATCH) > ret = gnutls_assert_val(GNUTLS_E_NO_CERTIFICATE_FOUND); > > - cleanup: > - gnutls_free(pubkey.data); > + // Cleanup unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120453570 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:15:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:15:58 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/verify-tofu.c: > + pubkey.size = cert->size; > + need_free = false; > + break; > + default: > + return gnutls_assert_val(GNUTLS_E_UNSUPPORTED_CERTIFICATE_TYPE); > } > > _gnutls_debug_log("Configuration file: %s\n", db_name); > > tdb->store(db_name, host, service, expiration, &pubkey); > > - ret = 0; > - > - cleanup: > - gnutls_free(pubkey.data); > + // Cleanup unnecessary comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120453764 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:17:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:17:12 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/verify-tofu.c: > * @expiration: The expiration time (use 0 to disable expiration) > * @flags: should be 0 or %GNUTLS_SCOMMIT_FLAG_ALLOW_BROKEN. > * > - * This function will store the provided hash commitment to > + * This function will store the provided hash commitment to > * the list of stored public keys. The key with the given > * hash will be considered valid until the provided expiration time. > * > - * The @store variable if non-null specifies a custom backend for > + * The @db_name variable if non-null specifies a custom backend for Nice catch here, though I think the right var should be 'tdb' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120454122 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:17:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:17:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/verify-tofu.c: > * @expiration: The expiration time (use 0 to disable expiration) > * @flags: should be 0. > * > - * This function will store the provided (raw or DER-encoded) certificate to > - * the list of stored public keys. The key will be considered valid until > - * the provided expiration time. > + * This function will store a raw public-key or a public-key provided via > + * a raw (DER-encoded) certificate to the list of stored public keys. The key > + * will be considered valid until the provided expiration time. > * > - * The @store variable if non-null specifies a custom backend for > + * The @db_name variable if non-null specifies a custom backend for same here, I think tdb is the right varname -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120454315 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:18:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:18:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on m4/hooks.m4: > AC_MSG_RESULT(yes) > fi > AM_CONDITIONAL(ENABLE_PSK, test "$ac_enable_psk" != "no") > - > + > ac_enable_anon=yes unnecessary change -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120454673 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:19:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:19:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/common-cert-key-exchange.c: > const gnutls_datum_t *client_cert, > const gnutls_datum_t *client_key, > unsigned cert_flags, > - unsigned exp_group) > + unsigned exp_group, > + gnutls_certificate_type_t server_ctype, > + gnutls_certificate_type_t client_ctype) > { > int ret; > char buffer[256]; > /* Server stuff. */ > - gnutls_certificate_credentials_t serverx509cred; > + gnutls_certificate_credentials_t server_crt_cred; maybe server_cred is more clear -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120454933 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:25:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:25:46 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: There are merge conflicts for this merge request. It cannot be merged automatically. Furthermore there are no unit tests for: * [ ] `gnutls_pcert_import_rawpk` * [ ] `gnutls_pcert_import_rawpk_raw` * [ ] `gnutls_certificate_set_rawpk_key_file` * [ ] `gnutls_certificate_get_rawpk_keypair` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120456820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:33:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:33:26 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Thank you for that merge request, I've completed the review and we don't need another if the issues noted are resolved. The most important are summarized above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120459471 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:36:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:36:03 +0000 Subject: [gnutls-devel] GnuTLS | Fix session description info printing (!821) In-Reply-To: References: Message-ID: Merge Request !821 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/821 Branches: tmp-fix-cs-description to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 16:36:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 15:36:02 +0000 Subject: [gnutls-devel] GnuTLS | Fix session description info printing (!821) In-Reply-To: References: Message-ID: Merged manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/821#note_120460243 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Nov 27 17:01:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 16:01:07 +0000 Subject: [gnutls-devel] GnuTLS | Fix some minor issue in the TPM test cases (!814) In-Reply-To: References: Message-ID: You are welcome. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/814#note_120468310 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 00:12:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 23:12:05 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/nettle/int/drbg-aes.c: > memset(seed, 0, DRBG_AES_SEED_SIZE); > } > > - /* Throw the first block generated. FIPS 140-2 requirement (see > - * the continuous random number generator test in 4.9.2) > - */ > - if (ctx->prev_block_present == 0) { > - INCREMENT(sizeof(ctx->v), ctx->v); > - aes256_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v); > - > - ctx->prev_block_present = 1; > - } > - Why did you drop this part? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120548777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 00:15:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 23:15:46 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on CONTRIBUTING.md: > be considered stable. > > > +# Introducing new features / modifying behavior > + > + The expectation on the introduction of a new feature which may affect > +already deployed code, e.g., a TLS extension is to have it disabled by > +default. That should be enabled when explicitly requested by the application. `... is to be disabled...`? I'm not a native though. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_120549137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 00:16:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 27 Nov 2018 23:16:37 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on CONTRIBUTING.md: > be considered stable. > > > +# Introducing new features / modifying behavior > + > + The expectation on the introduction of a new feature which may affect > +already deployed code, e.g., a TLS extension is to have it disabled by > +default. That should be enabled when explicitly requested by the application. > +That can be for example with a gnutls_init() flag. `That can happen` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_120549233 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 07:10:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 06:10:31 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: There are two reasons: first, the first block in ctx->prev_block never seems to be used anywhere. Thus, maintaining this ctx->prev_block would be meaningless these days. It used to be there to perform the memcmp with the current block to implement the FIPS 140-2 continuous self test. That is not required any more and thus the memcmp was removed. Yet, the copying of the previous block was still present. Second, for the ACVP testing, we need the very first block after initializaing a DRBG instance. In the past, I set the ctx->prev_block_present to 1 immediately after initializing in my test harness. But somehow that did not work. Instead of spending time to debug it, I felt to completely remove the code that seems to serve no purpose any more. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120604357 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 07:20:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 06:20:06 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: > There is a crash though when the library is run on > FIPS140 mode, which I could not figure why from the changes. This issue is now fixed. The GnuTLS library could not initialize in FIPS mode since the self test failed. I have updated the self test now to use an ACVP test that I just successfully verified yesterday. I took an ACVP test vector that contains the verification of personalization string and additional information to cover more code paths. Yet I removed the number of self tests from 3 to 1. If you think that more than one self test is beneficial, I can easily add more self tests using other ACVP test vectors I now have on file. The crash though is interesting: when I use the GnuTLS library without the updated self test in FIPS mode with my test harness, the library would simply not initialize and my application stops. The test, however, crashes. It seems that the test does not handle a failure in the initialization of GnuTLS gracefully. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120605715 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 12:06:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 11:06:51 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: The problem with the last one is that p11-kit has updated interface without actually updating version info. I'll workaround that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626#note_120680961 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 12:13:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 11:13:22 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) References: Message-ID: New Merge Request !823 https://gitlab.com/gnutls/gnutls/merge_requests/823 Project:Branches: GostCrypt/gnutls:ckm-eddsa to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality 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/823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 14:38:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 13:38:34 +0000 Subject: [gnutls-devel] GnuTLS | certtool: don't output textual information if --no-text was given (!810) In-Reply-To: References: Message-ID: After this MR, the travis macosx build started failing: https://travis-ci.org/gnutls/gnutls/builds/460195831 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/810#note_120723474 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 14:58:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 13:58:38 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) References: Message-ID: New Issue was created. Issue 628: https://gitlab.com/gnutls/gnutls/issues/628 Author: Nikos Mavrogiannopoulos Assignee: The travis macosx build started failing after !810: https://travis-ci.org/gnutls/gnutls/builds/460195831 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 14:58:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 13:58:59 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) In-Reply-To: References: Message-ID: @lumag if you could check it before the release on friday it would be great help! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628#note_120729565 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:04:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:04:58 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) References: Message-ID: New Merge Request !824 https://gitlab.com/gnutls/gnutls/merge_requests/824 Project:Branches: GostCrypt/gnutls:fix-mingw to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [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/824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:05:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:05:20 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: I think this might also fix #628 . -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824#note_120733139 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:06:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:06:01 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: Discovered while working on !823 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824#note_120733337 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:17:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:17:54 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) In-Reply-To: References: Message-ID: @Nikos 4 tests in `tests/cert-tests/` are failing, but the `after_failure:` code does not include the log files from that directory. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628#note_120745537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:19:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:19:05 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: make the usage of eddsa definitions conditional (!825) References: Message-ID: New Merge Request !825 https://gitlab.com/gnutls/gnutls/merge_requests/825 Branches: tmp-fix-mingw to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This addresses issues with compilation under mingw or in systems without a recent p11-kit. ## Checklist * [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/825 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:20:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:20:27 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: Reassigned Merge Request 823 https://gitlab.com/gnutls/gnutls/merge_requests/823 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:20:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:20:51 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: It seems we tried the same thing in parallel. Closing my MR and reviewing this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823#note_120753353 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:21:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:21:10 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: make the usage of eddsa definitions conditional (!825) In-Reply-To: References: Message-ID: Merge Request !825 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/825 Branches: tmp-fix-mingw to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/825 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:21:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:21:31 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: make the usage of eddsa definitions conditional (!825) In-Reply-To: References: Message-ID: Duplicate of !823 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/825#note_120753988 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:22:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:22:20 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: Merge Request !823 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/823 Project:Branches: GostCrypt/gnutls:ckm-eddsa to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 15:22:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 14:22:54 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: LGTM. I'll review manually if the mingw build succeed and merge in that case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823#note_120754583 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 16:56:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 15:56:14 +0000 Subject: [gnutls-devel] GnuTLS | Memory leak in gnutls_pkcs11_obj_list_import_url4(GNUTLS_PKCS11_OBJ_FLAG_WITH_PRIVKEY) (#629) References: Message-ID: New Issue was created. Issue 629: https://gitlab.com/gnutls/gnutls/issues/629 Author: Peter Wu Assignee: ## Description of problem: A memory leak is reported for `gnutls_pkcs11_obj_list_import_url4` requesting certificate + private keys. The context looks suspicious: ```c find_privkeys(struct pkcs11_session_info *sinfo, struct ck_token_info *tinfo, struct find_pkey_list_st *list) { // ... unsigned long count, current; current = 0; while (pkcs11_find_objects (sinfo->module, sinfo->pks, &ctx, 1, &count) == CKR_OK && count == 1) { // ... _gnutls_buffer_init(&list->key_ids[current]); if (pkcs11_get_attribute_value (sinfo->module, sinfo->pks, ctx, a, 1) == CKR_OK) { // ... current++; } if (current > list->key_ids_size) break; } // ... // Potential integer underflow if the above loop does not match? // Potentially loses track of the last element, causing a memleak? list->key_ids_size = current - 1; ``` ## Version of gnutls used: 3.5.18-1ubuntu1 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu 18.04 ## How reproducible: Steps to Reproduce: * Setup a PKCS#11 token (e.g. SoftHSM2). * `cc -g $(pkgconf --cflags --libs gnutls) repro.c -fsanitize=address && ./a.out` * Enter PIN code if requested and press Enter. ## Actual results: No error. ## Expected results: Memory leak report (first backtraces have been manually converted with `addr2line`): ``` ==17862==ERROR: LeakSanitizer: detected memory leaks Direct leak of 96 byte(s) in 1 object(s) allocated from: #0 0x56431559d219 in malloc (/shared/a.out+0xf2219) #1 0x7f8fba224e55 ./lib/pkcs11.c:2708 #2 0x7f8fba2260e9 ./lib/pkcs11.c:1420 #3 0x7f8fba22691b in gnutls_pkcs11_obj_list_import_url4 ./lib/pkcs11.c:3177 #4 0x5643155da92c in main /home/peter/work/hsm/demo/repro.c:27:13 #5 0x7f8fb920bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #6 0x5643154ca0bd in _start (/shared/a.out+0x1f0bd) Indirect leak of 6144 byte(s) in 3 object(s) allocated from: #0 0x56431559d6c8 in realloc (/shared/a.out+0xf26c8) #1 0x7f8fba2088b5 (/usr/lib/x86_64-linux-gnu/libgnutls.so.30+0x4c8b5) #2 0x7f8fba20bf77 in gnutls_buffer_append_data (/usr/lib/x86_64-linux-gnu/libgnutls.so.30+0x4ff77) #3 0x7f8fba22512a (/usr/lib/x86_64-linux-gnu/libgnutls.so.30+0x6912a) #4 0x7f8fba2260e9 (/usr/lib/x86_64-linux-gnu/libgnutls.so.30+0x6a0e9) #5 0x7f8fba22691b in gnutls_pkcs11_obj_list_import_url4 (/usr/lib/x86_64-linux-gnu/libgnutls.so.30+0x6a91b) #6 0x5643155da92c in main /home/peter/work/hsm/demo/repro.c:27:13 #7 0x7f8fb920bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #8 0x5643154ca0bd in _start (/shared/a.out+0x1f0bd) ``` repro.c ```c /* cc -g $(pkgconf --cflags --libs gnutls) repro.c -fsanitize=address */ #include #include #include #include #include static int pin_callback(void *userdata, int attempt, const char *token_url, const char *token_label, unsigned int flags, char *pin, size_t pin_max) { const char *pass = getpass("PIN: "); if (!pass || !pass[0]) { fprintf(stderr, "PIN retrieval failed.\n"); return -1; } strncpy(pin, pass, pin_max); return 0; } int main(int argc, char *argv[]) { const char *url = argc < 2 ? "pkcs11:" : argv[1]; gnutls_pkcs11_set_pin_function(pin_callback, NULL); gnutls_pkcs11_obj_t *list = NULL; unsigned int nlist = 0; int ret = gnutls_pkcs11_obj_list_import_url4( &list, &nlist, url, GNUTLS_PKCS11_OBJ_FLAG_CRT | GNUTLS_PKCS11_OBJ_FLAG_WITH_PRIVKEY | GNUTLS_PKCS11_OBJ_FLAG_LOGIN); if (ret < 0) { fprintf(stderr, "import_url failed: %d (%s)\n", ret, gnutls_strerror(ret)); } else { for (unsigned j = 0; j < nlist; j++) { gnutls_pkcs11_obj_deinit(list[j]); } gnutls_free(list); } } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:51:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:51:12 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: Merge Request !824 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/824 Project:Branches: GostCrypt/gnutls:fix-mingw to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:51:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:51:15 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: Merge Request !824 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/824 Project:Branches: GostCrypt/gnutls:fix-mingw to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:51:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:51:37 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: Reassigned Merge Request 824 https://gitlab.com/gnutls/gnutls/merge_requests/824 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:51:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:51:42 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:51:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:51:48 +0000 Subject: [gnutls-devel] GnuTLS | tests: fix crl test under MinGW32/64 (!824) In-Reply-To: References: Message-ID: LGTM, thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/824#note_120861002 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:53:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:53:06 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: Interestingly now the error is detected. I do not get how gitlab reads the error code. Anyway it should only need a rebase to succeed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823#note_120861227 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:53:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:53:55 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Merge Request !820 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/820 Project:Branches: smuellerDD/gnutls:drbg to gnutls/gnutls:master Author: Stephan Mueller Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:54:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:54:19 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:54:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:54:14 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: LGTM. Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120861453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:54:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:54:17 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Reassigned Merge Request 820 https://gitlab.com/gnutls/gnutls/merge_requests/820 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:54:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:54:33 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: All discussions on Merge Request !820 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/820 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 19:55:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 18:55:02 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/int/drbg-aes.c: > memset(seed, 0, DRBG_AES_SEED_SIZE); > } > > - /* Throw the first block generated. FIPS 140-2 requirement (see > - * the continuous random number generator test in 4.9.2) > - */ > - if (ctx->prev_block_present == 0) { > - INCREMENT(sizeof(ctx->v), ctx->v); > - aes256_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v); > - > - ctx->prev_block_present = 1; > - } > - If you think is resolved, I think we are read for merge -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_120861571 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:00:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:00:53 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on CONTRIBUTING.md: > be considered stable. > > > +# Introducing new features / modifying behavior > + > + The expectation on the introduction of a new feature which may affect > +already deployed code, e.g., a TLS extension is to have it disabled by > +default. That should be enabled when explicitly requested by the application. Not the best expression indeed. Corrected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_120862641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:01:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:01:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on CONTRIBUTING.md: > be considered stable. > > > +# Introducing new features / modifying behavior > + > + The expectation on the introduction of a new feature which may affect > +already deployed code, e.g., a TLS extension is to have it disabled by > +default. That should be enabled when explicitly requested by the application. > +That can be for example with a gnutls_init() flag. Updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_120862679 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:01:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:01:04 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: All discussions on Merge Request !816 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/816 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:12:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:12:42 +0000 Subject: [gnutls-devel] GnuTLS | WIP: CONTRIBUTING.md: added proposal on commenting style and new features (!816) In-Reply-To: References: Message-ID: I have added a new patch adding a sentence for static/inline functions clarifying the current situation (in these we are not using the `_gnutls` prefix consistently). Thus I removed the requirement and went for the simplest way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/816#note_120869605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:17:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:17:30 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. > CTYPE-CLI-X509 or CTYPE-CLI-X.509, CTYPE-SRV-X509 or CTYPE-SRV-X.509. > +CTYPE-CLI-RAWPK or CTYPE-CLI-RAWPUBKEY, CTYPE-SRV-RAWPK or CTYPE-SRV-RAWPUBKEY. It does not have to be too elaborate or nothing :) It can be `The currently supported types are CTYPE-X509, CTYPE-RAWPK or CTYPE-RAWPUBKEY which apply both to server and client, with catch all being CTYPE-ALL. The types CTYPE-CLI-X509, CTYPE-SRV-X509, CTYPE-SRV-X509, CTYPE-CLI-RAWPK, CTYPE-SRV-RAWPK can be used to specialize on server or client. The 'X509' is aliased to 'X.509' for legacy reasons`. (btw. why do we alias RAWPUBKEY we do not have any such legacy requirement, so why give a choice here?) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120871036 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 20:30:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 19:30:50 +0000 Subject: [gnutls-devel] GnuTLS | Memory leak in gnutls_pkcs11_obj_list_import_url4(GNUTLS_PKCS11_OBJ_FLAG_WITH_PRIVKEY) (#629) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 21:24:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 20:24:58 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. > CTYPE-CLI-X509 or CTYPE-CLI-X.509, CTYPE-SRV-X509 or CTYPE-SRV-X.509. > +CTYPE-CLI-RAWPK or CTYPE-CLI-RAWPUBKEY, CTYPE-SRV-RAWPK or CTYPE-SRV-RAWPUBKEY. >(btw. why do we alias RAWPUBKEY we do not have any such legacy requirement, so why give a choice here?) That's true. I added the `RAWPUBKEY` alias because its a little more readable than `RAWPK`. But yes I can remove it to keep things simple. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120884220 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 21:42:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 20:42:42 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: @nmav I tried to find the logic in error codes, but failed after a quick glance. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823#note_120889626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 22:21:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 21:21:55 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/pcert.c: > +{ > + /* For convenience we reuse the internal pcert structure to hold > + * our raw public key. By doing so we only need one certificate > + * structure that can hold multiple certificate-like credential > + * types. > + */ > + int ret; > + > + if (pubkey == NULL) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + } > + > + memset(pcert, 0, sizeof(*pcert)); > + > + /* A pcert struct holds a raw copy of the certificate data. > + * Therefore we convert our gnutls_pubkey_t to its raw DER The key thing to document here is that we need to export the key in DER format. This info is relevant for a developer but not for the user of this API. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120895312 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 22:53:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 21:53:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) References: Message-ID: New Issue was created. Issue 631: https://gitlab.com/gnutls/gnutls/issues/631 Author: Jonathan Brielmaier Assignee: ## Description of problem: Building gnutls from source, better from the release tarball, doesn't work with guile 2.2. ## Version of gnutls used: 3.6.4 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) openSUSE Tumbleweed Steps to Reproduce: * environment with guile 2.2 only * extract release tarball from ftp.gnutls.org * run ./configure ## Actual results: ``` checking pkg-config is at least version 0.9.0... yes configure: error: in `/home/abuild/rpmbuild/BUILD/gnutls-3.6.4': configure: error: searching for guile development files for versions 2.0 1.8, but previously found /usr/bin/guile version 2.2 ``` For openSUSE I created a little patch to bypass this error. ``` --- gnutls-3.6.4/aclocal.m4.orig 2018-10-16 17:52:16.972960988 +0200 +++ gnutls-3.6.4/aclocal.m4 2018-10-16 17:52:32.797099492 +0200 @@ -162,7 +162,7 @@ # AC_DEFUN([GUILE_PKG], [PKG_PROG_PKG_CONFIG - _guile_versions_to_search="m4_default([$1], [2.0 1.8])" + _guile_versions_to_search="m4_default([$1], [2.2 2.0 1.8])" if test -n "$GUILE_EFFECTIVE_VERSION"; then _guile_tmp="" for v in $_guile_versions_to_search; do --- gnutls-3.6.4/configure.orig 2018-10-16 18:00:13.661141247 +0200 +++ gnutls-3.6.4/configure 2018-10-16 18:00:29.857283556 +0200 @@ -62704,7 +62704,7 @@ PKG_CONFIG="" fi fi - _guile_versions_to_search="2.0 1.8" + _guile_versions_to_search="2.2 2.0 1.8" if test -n "$GUILE_EFFECTIVE_VERSION"; then _guile_tmp="" for v in $_guile_versions_to_search; do ``` Can this issue be fixed in the next release or is there anything block guile 2.2? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 23:02:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 22:02:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/session.c: > - gnutls_certificate_type_get_name(ctype_client)); > - } else { > - // print proto version, client cert type, server cert type > - snprintf(proto_name, sizeof(proto_name), "%s-%s-%s", > - gnutls_protocol_get_name(get_num_version(session)), > - gnutls_certificate_type_get_name(ctype_client), > - gnutls_certificate_type_get_name(ctype_server)); > - } > - } else { // Assumed default certificate type (X.509) > - snprintf(proto_name, sizeof(proto_name), "%s", > - gnutls_protocol_get_name(get_num_version > - (session))); > + // Get certificate types > + ctype_client = _gnutls_certificate_type_get2(session, GNUTLS_CTYPE_CLIENT); > + ctype_server = _gnutls_certificate_type_get2(session, GNUTLS_CTYPE_SERVER); > + I did that on purpose to always show the cert type. But I'll change it back. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120900758 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Nov 28 23:39:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 22:39:20 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/ext/cert_types.h: > + return true; > + case GNUTLS_CRT_RAWPK: > + return session->internals.flags & GNUTLS_ENABLE_RAWPK; > + default: > + // When not explicitly supported here disable it > + return false; > + } > +} > + > +/* Checks whether alternative cert types (i.e. other than X.509) > + * are enabled in the application > + */ > +static inline bool _gnutls_are_alternative_cert_types_allowed(gnutls_session_t session) > +{ > + // OR-ed list of defined cert type init flags > + uint64_t cert_types_flags = GNUTLS_ENABLE_RAWPK; I used the `uint64_t` here because it's exactly as big as the `flags` field in `internals_st`. A define would occupy just as much space is needed but the disadvantage is that is ends up in global scope whereas this declaration is local to the function (the only place where is actually needs to live). I can change it into a define if you like but I'm curious what your main concern here is? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120904925 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 00:16:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 23:16:39 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, > + * and the openssl format and will be autodetected. > + * > + * If the raw public-key and the private key are given in PEM encoding > + * then the strings that hold their values must be null terminated. > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Note that, this function by default returns zero on success and a > + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2 To be honest I think that this cert API v2 is not the best solution for the problem. In my opinion it is not consistent with the rest of the API where only status codes are returned. I think it would have been nicer to let all functions only return a status code. If you want to return an other value you should do it via a parameter. I actually wanted to start a separate discussion about this topic. Is it okay when we discuss that in a separate issue? Just tell me how you want me to update this new API and I will change it. I think that it would be nice to leave it this way for consistency reasons with the rest of the cert API. But it's your call. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120908676 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 00:18:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 23:18:52 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * #gnutls_certificate_credentials_t type to be used for authentication > + * and/or encryption. @subject_public_key_info and @privkey should match > + * otherwise set signatures cannot be validated. This function should > + * be called once for the client because there is currently no mechanism > + * to determine which raw public-key to select for the peer when there > + * are multiple present. Multiple raw public keys for the server can be > + * distinghuished by setting the @names. > + * > + * Note here that @subject_public_key_info is a raw public-key as defined > + * in RFC7250. It means that there is no surrounding certificate that > + * holds the public key and that there is therefore no direct mechanism > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, I don't know a lot about these formats. Since I used the same function as the X509 routines to import the keys I also copied the same comment from these functions with respect to the supported formats. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120908892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 00:26:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 23:26:07 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + > + // A complete key pair must be given > + if (rawpkfile == NULL || privkeyfile == NULL) { > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + } > + > + /* Import our private key. This function does all the necessary > + * inits, checks and imports. */ > + ret = _gnutls_read_key_file(cred, privkeyfile, format, pass, flags, &privkey); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // TODO FUTURE: support URLs > + if (gnutls_url_is_supported(rawpkfile)) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); I didn't know about this function. I'll incorporate it. Why is it that the `*_file()` API handles URLs and we don't have a separate API for it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120909586 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 00:33:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 28 Nov 2018 23:33:42 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST As far as I can tell this is already the case according to documentation and implementation. Did I miss something? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120910321 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 04:00:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 03:00:32 +0000 Subject: [gnutls-devel] GnuTLS | MinGW CI runners fail to build GnuTLS but succeed (#626) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #626: https://gitlab.com/gnutls/gnutls/issues/626 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 04:00:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 03:00:33 +0000 Subject: [gnutls-devel] GnuTLS | lib: fix pkcs11 using defines from PKCS#11 3.0 for EdDSA (!823) In-Reply-To: References: Message-ID: Merge Request !823 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/823 Project:Branches: GostCrypt/gnutls:ckm-eddsa to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 09:33:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 08:33:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: The guile detection is in `configure.ac`, would you like to send a merge request to address this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_120983158 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 09:33:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 08:33:57 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 09:34:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 08:34:01 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 09:52:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 08:52:01 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/cert_types.h: > + return true; > + case GNUTLS_CRT_RAWPK: > + return session->internals.flags & GNUTLS_ENABLE_RAWPK; > + default: > + // When not explicitly supported here disable it > + return false; > + } > +} > + > +/* Checks whether alternative cert types (i.e. other than X.509) > + * are enabled in the application > + */ > +static inline bool _gnutls_are_alternative_cert_types_allowed(gnutls_session_t session) > +{ > + // OR-ed list of defined cert type init flags > + uint64_t cert_types_flags = GNUTLS_ENABLE_RAWPK; A define does not get stored in any scope. It is being expanded by the pre-processor. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120993205 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:01:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:01:35 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: @nmav I believe that you only need a recent enough system where you build the tarball. E.g. on my system the above patched lines are already there. I'll attach it as reference. [aclocal.m4](/uploads/e221e01ae8d46f432dfd58ad6efb7757/aclocal.m4) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_120995932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:12:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:12:33 +0000 Subject: [gnutls-devel] GnuTLS | Test mingw macos (!826) References: Message-ID: New Merge Request !826 https://gitlab.com/gnutls/gnutls/merge_requests/826 Project:Branches: GostCrypt/gnutls:test-mingw-macos to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fix `certtool --no-text` tests on Mac OS X (see https://travis-ci.org/GostCrypt/gnutls/builds/461098580). ## Checklist * [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/826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:26:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:26:58 +0000 Subject: [gnutls-devel] GnuTLS | Fix MacOS X builds (!826) In-Reply-To: References: Message-ID: Merge Request !826 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/826 Project:Branches: GostCrypt/gnutls:test-mingw-macos to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:28:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:28:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, > + * and the openssl format and will be autodetected. > + * > + * If the raw public-key and the private key are given in PEM encoding > + * then the strings that hold their values must be null terminated. > + * > + * Key usage (as defined by X.509 extension (2.5.29.15)) can be explicitly > + * set because there is no certificate structure around the key to define > + * this value. See for more info gnutls_x509_crt_get_key_usage(). > + * > + * Note that, this function by default returns zero on success and a > + * negative value on error. Since 3.5.6, when the flag %GNUTLS_CERTIFICATE_API_V2 Ok, let's leave it supporting the same options with the other APIs. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121003872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:29:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:29:36 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + * #gnutls_certificate_credentials_t type to be used for authentication > + * and/or encryption. @subject_public_key_info and @privkey should match > + * otherwise set signatures cannot be validated. This function should > + * be called once for the client because there is currently no mechanism > + * to determine which raw public-key to select for the peer when there > + * are multiple present. Multiple raw public keys for the server can be > + * distinghuished by setting the @names. > + * > + * Note here that @subject_public_key_info is a raw public-key as defined > + * in RFC7250. It means that there is no surrounding certificate that > + * holds the public key and that there is therefore no direct mechanism > + * to prove the authenticity of this key. The keypair can be used during > + * a TLS handshake but its authenticity should be established via a > + * different mechanism (e.g. TOFU or known fingerprint). > + * > + * The supported formats are basic unencrypted key, PKCS8, PKCS12, ok, that could be an optimization to consider in the future. Resolving. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121004200 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:30:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:30:19 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + > + // A complete key pair must be given > + if (rawpkfile == NULL || privkeyfile == NULL) { > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + } > + > + /* Import our private key. This function does all the necessary > + * inits, checks and imports. */ > + ret = _gnutls_read_key_file(cred, privkeyfile, format, pass, flags, &privkey); > + if (ret < 0) { > + return gnutls_assert_val(ret); > + } > + > + // TODO FUTURE: support URLs > + if (gnutls_url_is_supported(rawpkfile)) { > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); So that it works with existing applications and the user can replace a file with a URI transparently. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121004446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 10:36:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 09:36:12 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST I do not see the text "If the public key with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST is returned" in gnutls_certificate_get_crt_raw(). Furthermore: > ```With this function you can retrieve, and if desired, overwrite a previously set key pair.``` This should be removed. We don't provide modify access to internal data, period. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121006236 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 11:00:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 10:00:59 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/nettle/int/drbg-aes.c: > memset(seed, 0, DRBG_AES_SEED_SIZE); > } > > - /* Throw the first block generated. FIPS 140-2 requirement (see > - * the continuous random number generator test in 4.9.2) > - */ > - if (ctx->prev_block_present == 0) { > - INCREMENT(sizeof(ctx->v), ctx->v); > - aes256_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v); > - > - ctx->prev_block_present = 1; > - } > - I did not yet have time to cross-check FIPS 140-2 and SP 800-90A that we are allowed not to drop first block. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_121014428 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 12:03:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 11:03:48 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST The `gnutls_certificate_get_crt_raw()` function just returns the raw certificate data (in DER encoding). It doesn't look at the certificate type. The user that calls this function must know how to interpret the data (i.e. whether it's a x509 cert or raw pubkey). Therefore I think it doesn't make sense to check for a cert type here (we even don't have a parameter for that) and thus we can not return a `%GNUTLS_E_INVALID_REQUEST`. The `gnutls_certificate_get_x509_key()` and `gnutls_certificate_get_x509_crt()` functions however actually do a cert type check and are in line with `gnutls_certificate_get_rawpk_keypair`. Do you agree that we should leave `gnutls_certificate_get_crt_raw()` the way it is now? > This should be removed. We don't provide modify access to internal data, period. I will change this -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121035181 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 12:40:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 11:40:31 +0000 Subject: [gnutls-devel] GnuTLS | Fix MacOS X builds (!826) In-Reply-To: References: Message-ID: Merge Request !826 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/826 Project:Branches: GostCrypt/gnutls:test-mingw-macos to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 13:02:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 12:02:44 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/nettle/int/drbg-aes.c: > memset(seed, 0, DRBG_AES_SEED_SIZE); > } > > - /* Throw the first block generated. FIPS 140-2 requirement (see > - * the continuous random number generator test in 4.9.2) > - */ > - if (ctx->prev_block_present == 0) { > - INCREMENT(sizeof(ctx->v), ctx->v); > - aes256_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v); > - > - ctx->prev_block_present = 1; > - } > - To my understanding, the test is still mentioned in [FIPS140-2 document, section 4.9.2](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf). However the [newest implementation guide](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Module-Validation-Program/documents/fips140-2/FIPS1402IG.pdf) in section 9.8 claims: > In view of the considerations stated above, the requirement to pass the CRNGT is interpreted as follows. > The SP-800-90A-compliant DRBGs are not required to perform the test as described in AS.09.42 and AS.09.43 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_121050933 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 13:11:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 12:11:12 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST > The `gnutls_certificate_get_crt_raw()` function just returns the raw certificate data (in DER encoding). It doesn't look at the certificate type. The user that calls this function must know how to interpret the data (i.e. whether it's a x509 cert or raw pubkey). Therefore I think it doesn't make sense to check for a cert type here (we even don't have a parameter for that) and thus we can not return a `%GNUTLS_E_INVALID_REQUEST`. So you say it is applicable to both raw and x509. So it is ok. In that case why do we introduce the special function to get raw keys with no equivalent in the x509 set? Do you have a particular use case for it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121052969 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 13:18:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 12:18:31 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) In-Reply-To: References: Message-ID: This was addressed by: https://gitlab.com/gnutls/gnutls/commit/feea70eb5639fcdbdbc7572370677dbafda7aea5 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628#note_121054971 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 13:18:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 12:18:32 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #628: https://gitlab.com/gnutls/gnutls/issues/628 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 13:18:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 12:18:42 +0000 Subject: [gnutls-devel] GnuTLS | macosx CI fails (#628) In-Reply-To: References: Message-ID: Reassigned Issue 628 https://gitlab.com/gnutls/gnutls/issues/628 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 15:55:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 14:55:11 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) References: Message-ID: New Issue was created. Issue 632: https://gitlab.com/gnutls/gnutls/issues/632 Author: Paul F.B. Assignee: I am not sure if this is a bug or something intended. Analyzing models of the GnuTLS DTLS server implementation by [state learning](http://www.cs.ru.nl/~joeri/StateMachineInference.html), I noticed that the DTLS server will initially respond with HELLO_VERIFY_REQUEST to not only to CLIENT_HELLO messages, but also to most other messages. Attached is a Wireshark capture of GnuTLS v. 3.5.19 doing this for a FINISHED message, and actually completing the handshake, plus the model obtained (viewable via xdot, BTW I couldn't find much else wrong in it). This is reproducible also on the latest GnuTLS version. The command for running the server is: `gnutls-serv --udp --disable-client-cert --pskpasswd some_path_to_keys --port 20000 --priority NORMAL:+PSK:+SRP` I was wondering if this was intended behavior. It seems weird, as the DTLS specification is quite clear about the flow of a handshake (CLIENT_HELLO/HELLO_VERIFY_REQUEST CLIENT_HELLO/SERVER_HELLO...). Weirder still, HELLO_VERIFY_REQUEST is sent also in response to ALERT messages. [gnutls_onehello_handshake.pcapng](/uploads/3316243dd059d5796db178cb3bdfcb31/gnutls_onehello_handshake.pcapng) [gnutls.dot](/uploads/527dae5bd07038c5f81110bb86c8cc98/gnutls.dot) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 19:02:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 18:02:28 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) References: Message-ID: New Merge Request !827 https://gitlab.com/gnutls/gnutls/merge_requests/827 Project:Branches: Lekensteyn/gnutls:fix-token-info-modname to gnutls/gnutls:master Author: Peter Wu Assignee: Fixes a memleak and some inconsistent behavior when the output buffer is too short. Not sure if it is worth documenting presence of such bugs in the function documentation, I noticed a crash when using this pattern: ```c size = 0; ret = gnutls_pkcs11_token_get_info(url, GNUTLS_PKCS11_TOKEN_MODNAME, NULL, &size); /* error handling for ret */ buffer = g_malloc(size); ret = gnutls_pkcs11_token_get_info(url, GNUTLS_PKCS11_TOKEN_MODNAME, buffer, &size); ```` Note that with the "consistency fix", the above has to be changed to this: ```c size = 0; ret = gnutls_pkcs11_token_get_info(url, GNUTLS_PKCS11_TOKEN_MODNAME, NULL, &size); /* error handling for ret */ ++size; /* include memory for NULL terminator */ buffer = g_malloc(size); ret = gnutls_pkcs11_token_get_info(url, GNUTLS_PKCS11_TOKEN_MODNAME, buffer, &size); ```` ## Checklist * [ ] 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/827 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 20:09:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 19:09:17 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PKCS11_TOKEN_MODNAME is unavailable when a provider is manually loaded (#633) References: Message-ID: New Issue was created. Issue 633: https://gitlab.com/gnutls/gnutls/issues/633 Author: Peter Wu Assignee: ## Description of problem: When a provider is manually loaded, the module name is not available for some reason. This can also be reproduced with `p11tool`. There is another example of this issue here reported for Fedora 28: https://github.com/p11-glue/p11-kit/issues/172#issuecomment-398852836 ## Version of gnutls used: 3.5.18-1ubuntu1 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu 18.04. ## How reproducible: The following outputs should be equivalent: ``` $ p11tool --list-tokens $ p11tool --list-tokens --provider=/usr/lib/softhsm/libsofthsm2.so ``` ## Actual results: ``` $ p11tool --list-tokens --provider=/usr/lib/softhsm/libsofthsm2.so Token 0: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=f7101470c14e7525;token=mytoken Label: mytoken Type: Generic token Manufacturer: SoftHSM project Model: SoftHSM v2 Serial: f7101470c14e7525 Module: (null) ``` ## Expected results: ``` $ p11tool --list-tokens --provider=/usr/lib/softhsm/libsofthsm2.so Token 0: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=f7101470c14e7525;token=mytoken Label: mytoken Type: Generic token Manufacturer: SoftHSM project Model: SoftHSM v2 Serial: f7101470c14e7525 Module: /usr/lib/softhsm/libsofthsm2.so ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/633 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 22:44:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 21:44:40 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: All discussions on Merge Request !820 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/820 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Nov 29 22:44:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 21:44:39 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/nettle/int/drbg-aes.c: > memset(seed, 0, DRBG_AES_SEED_SIZE); > } > > - /* Throw the first block generated. FIPS 140-2 requirement (see > - * the continuous random number generator test in 4.9.2) > - */ > - if (ctx->prev_block_present == 0) { > - INCREMENT(sizeof(ctx->v), ctx->v); > - aes256_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v); > - > - ctx->prev_block_present = 1; > - } > - Judging from that part and from SP-800-90A it is not necessary. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_121230948 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 00:36:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 29 Nov 2018 23:36:08 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-rawpk.c: > + * > + * Obtains pointers to a public/private key pair that has been stored in > + * @cred with one of gnutls_certificate_set_key(), > + * gnutls_certificate_set_rawpk_key_mem() or gnutls_certificate_set_rawpk_key_file(). > + * The returned keys must NOT be deallocated since they point directly > + * to the keys in the credentials struct. With this function you can > + * retrieve, and if desired, overwrite a previously set key pair. > + * > + * A correct @index can be retrieved as the return value from a > + * gnutls_certificate_set_key(), gnutls_certificate_set_rawpk_key_mem() > + * or gnutls_certificate_set_rawpk_key_file() function when the > + * %GNUTLS_CERTIFICATE_API_V2 flag is set. > + * > + * If there is no key with the given index, > + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. If the public key > + * with the given index is not a raw public key, %GNUTLS_E_INVALID_REQUEST > So you say it is applicable to both raw and x509. So it is ok. Yes. > In that case why do we introduce the special function to get raw keys with no equivalent in the x509 set? Do you have a particular use case for it? There are equivalent functions for x509 in `cert-cred-x509.c` called `gnutls_certificate_get_x509_key()` and `gnutls_certificate_get_x509_crt()`. My function for retrieving a raw public-key only retrieves both the private key and public key together (i.e. retrieves the key pair). That reduces the number of new API functions and most of the time you want to retrieve both of them anyway. You also set them together so I think it's logical to retrieve them together. If your question is why do we have `gnutls_certificate_get_crt_raw()`, that I don't know. It was already there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121243602 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 01:42:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 00:42:15 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: I have the feeling that 3.6.5/3.6.6/etc should be milestones, while 3.6.x/tls1.3/etc should be labels. This way we would be able to limit boards to just relevant issues, while keeping milestone-like approach to per-relase bugs. In fact I miss board-like representation for merge requests. I see no simple way to automate presenting per-series merge requests or e.g. MRs only targeting 3.6.x. There are filters, of course, but they are not as visually-oriented as boards are. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_121248726 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:07:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:07:39 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Merge Request !820 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/820 Project:Branches: smuellerDD/gnutls:drbg to gnutls/gnutls:master Author: Stephan Mueller Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:07:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:07:55 +0000 Subject: [gnutls-devel] GnuTLS | DRBG: Remove all traces of FIPS 140-2 continuous self test (!820) In-Reply-To: References: Message-ID: Thank you @smuellerDD -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/820#note_121285102 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:14:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:14:00 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pkcs11.c: > len = p11_kit_space_strlen(str, str_max); > > if (len + 1 > *output_size) { > - *output_size = len + 1; Nice catch. Indeed this is incorrect behavior as an application will not be able to allocate the right amount of data. It is "breaking" the ABI, but according to debian code search this function is not yet used. So the risk of fixing this issue is quite low. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/827#note_121285973 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:14:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:14:04 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) In-Reply-To: References: Message-ID: Reassigned Merge Request 827 https://gitlab.com/gnutls/gnutls/merge_requests/827 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/827 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:21:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:21:10 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) In-Reply-To: References: Message-ID: Would you like to introduce a unit test of the use of this flag? You can modify tests in tests/pkcs11/ or introduce a new one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/827#note_121286870 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:33:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:33:56 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: Makes sense. I'll try to convert on the first opportunity. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_121288939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:40:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:40:46 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: What you see could be multiple things: 1. an issue in the networking stack that makes you see that packet multiple times 2. an issue in the server application (gnutls-serv) 3. an issue in the library Could you provide a reproducer (e.g., modify one of the DTLS tests in tests/)? That would help eliminate (3), and limit options to (2) or (1). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632#note_121290079 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:40:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:40:55 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: Milestone changed to GnuTLS 3.6.x bug fixes ( https://gitlab.com/gnutls/gnutls/milestones/11 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 08:59:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 07:59:34 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: That was relatively easy, however the release cadence was documented in the milestones, that would have to move somewhere else. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_121293521 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:04:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:04:57 +0000 Subject: [gnutls-devel] GnuTLS | 3.3.x: Prevent SHA1 from being used for certificate verification by default (#175) In-Reply-To: References: Message-ID: Given that 3.3.x is close to its end of life it does not make sense to pursue this change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/175#note_121294454 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:04:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:04:58 +0000 Subject: [gnutls-devel] GnuTLS | 3.3.x: Prevent SHA1 from being used for certificate verification by default (#175) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #175: https://gitlab.com/gnutls/gnutls/issues/175 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/175 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:02 +0000 Subject: [gnutls-devel] GnuTLS | Slow loading of CA certificates (#138) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/138 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:03 +0000 Subject: [gnutls-devel] GnuTLS | Add verify support for policies, and inhibit any policy (#195) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/195 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:07 +0000 Subject: [gnutls-devel] GnuTLS | Rename key set functions (API) to reflect the fact that they set a key pair (#608) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:02 +0000 Subject: [gnutls-devel] GnuTLS | Support PKCS 7 decryption (#152) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/152 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:04 +0000 Subject: [gnutls-devel] GnuTLS | reduce CI runs to less than 60 mins (#292) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/292 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:06 +0000 Subject: [gnutls-devel] GnuTLS | use TAP driver for tests (#423) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/423 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:03 +0000 Subject: [gnutls-devel] GnuTLS | Include advanced test suite for verification over PKCS#11 (#157) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/157 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:05 +0000 Subject: [gnutls-devel] GnuTLS | namespace error when gnutls-cli connects to XMPP s2s port (#319) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/319 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:06 +0000 Subject: [gnutls-devel] GnuTLS | Support ESNI (#595) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/595 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:03 +0000 Subject: [gnutls-devel] GnuTLS | Remove the support for SRP protocol (#201) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/201 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:05 +0000 Subject: [gnutls-devel] GnuTLS | consider using an alternative build system (#320) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/320 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:03 +0000 Subject: [gnutls-devel] GnuTLS | Failure to decrypt key in ISO8859-2 locale (#206) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/206 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:05 +0000 Subject: [gnutls-devel] GnuTLS | pkg-config file does not contain the right libraries under windows (#412) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/412 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:05 +0000 Subject: [gnutls-devel] GnuTLS | provide bash tab completion for gnutls-cli, gnutls-serv, and certtool (#348) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/348 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:04 +0000 Subject: [gnutls-devel] GnuTLS | ocsptool: no option to dermine whether a certificate corresponds to a response (#216) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/216 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:03 +0000 Subject: [gnutls-devel] GnuTLS | Add support for PKCS#8v2 (asymetric key packages) (#213) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/213 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:05 +0000 Subject: [gnutls-devel] GnuTLS | clean up log functions (#296) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/296 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:04 +0000 Subject: [gnutls-devel] GnuTLS | Switch to another ASN.1 DER/BER parsing back-end (#226) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/226 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:06 +0000 Subject: [gnutls-devel] GnuTLS | cryptodev: add testsuite or remove support (#415) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/415 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:11:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:11:04 +0000 Subject: [gnutls-devel] GnuTLS | add codacy badge to first page (#287) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/287 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli - incomplete DANE support (#557) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/557 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:56 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:59 +0000 Subject: [gnutls-devel] GnuTLS | Memory leak in gnutls_pkcs11_obj_list_import_url4(GNUTLS_PKCS11_OBJ_FLAG_WITH_PRIVKEY) (#629) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:59 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:55 +0000 Subject: [gnutls-devel] GnuTLS | Unclear extent of functionality of danetool --check (#558) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/558 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:57 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS chokes on two examples from RFC 4134 (#612) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:58 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS continue in a conversation when second ClienHello is different than the first CH, in HRR. (#617) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/617 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:56 +0000 Subject: [gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:58 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert description in Alert Message (#618) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:55 +0000 Subject: [gnutls-devel] GnuTLS | testcompat-main-openssl fails - 140270991812416:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310: (#572) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/572 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:59 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:56 +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 Fri Nov 30 09:12:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:58 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PCERT_NO_CERT is unused (#624) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/624 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:36 +0000 Subject: [gnutls-devel] GnuTLS | [Docs] Update documentation on TLS hello extensions (#437) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/437 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from 1163307648@qq.com): Some little defects and suggestions for GnuTLS 3.6.0 certificate verification module. (#474) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/474 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:39 +0000 Subject: [gnutls-devel] GnuTLS | improve documentation on certificate authentication (#540) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/540 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:41 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS does not handle long lists in signature_algorithms correctly (#555) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/555 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:56 +0000 Subject: [gnutls-devel] GnuTLS | tests: ensure that tests which override library functions run (#589) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/589 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | When there are multiple defects in the same certificate, only one error warning is given. (#494) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/494 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:39 +0000 Subject: [gnutls-devel] GnuTLS | improve test suite of gnutls-cli (#536) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/536 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:40 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from tk@giga.or.at): gnutls-3.6.3: two problems on NetBSD (#544) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/544 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:36 +0000 Subject: [gnutls-devel] GnuTLS | consider automating the .map file generation (#465) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/465 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | Hardware acceleration on IOS armv8 (#475) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/475 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:39 +0000 Subject: [gnutls-devel] GnuTLS | trailing dot needs to be stripped for certificate matching (#521) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/521 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:56 +0000 Subject: [gnutls-devel] GnuTLS | Getting error "Please insert token 'TEE_TOKEN' in slot and press enter" on searching private objects. (#583) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/583 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | further improve the TLS1.0/1.1 decoding of CBC record ciphers (#503) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/503 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:40 +0000 Subject: [gnutls-devel] GnuTLS | Valid cert fails to verify due to different DN encodings (#553) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/553 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:55 +0000 Subject: [gnutls-devel] GnuTLS | automate coverity checks (#574) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/574 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:39 +0000 Subject: [gnutls-devel] GnuTLS | test the reception of multiple and split async handshake messages (NST) (#511) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/511 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:57 +0000 Subject: [gnutls-devel] GnuTLS | certtool --p7-info should parse PKCS#7 attributes (#611) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/611 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:40 +0000 Subject: [gnutls-devel] GnuTLS | coverage drop (#550) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/550 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:28 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli should offer a way to set hostname independently of IP Address (bypassing DNS) (#344) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/344 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:30 +0000 Subject: [gnutls-devel] GnuTLS | "initialization from incompatible pointer type" when building with --enable-cryptodev flag set during configure. (#406) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/406 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:36 +0000 Subject: [gnutls-devel] GnuTLS | Provide an option to require encrypt-then-mac on server side (#472) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/472 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:28 +0000 Subject: [gnutls-devel] GnuTLS | [Documentation issue] References in the Preface aren't links or expanded as a footnote (#321) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/321 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from b.cama@kerlink.fr): Certtool Segfaults when called with --certificate-pubkey (#368) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/368 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | Allow applications to use different sets of credentials per vhost (#382) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/382 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:31 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS modifies multi-value RDN certificate subject before sending (#403) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/403 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | [clang-cl] missing _xgetbv() during link (#372) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/372 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_get_data_mtu() can return smaller values than passed to gnutls_set_data_mtu() (#360) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/360 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:30 +0000 Subject: [gnutls-devel] GnuTLS | Undefined behavior in pk.c (#402) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/402 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | Failed to build master (missing gnutls_hkdf_expand) (#401) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/401 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:37 +0000 Subject: [gnutls-devel] GnuTLS | certtool: --ask-pass option does not work with PKCS#8 encoded private key (#436) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/436 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | mingw: builds failing (#493) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/493 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | Integer wrap around in gnutls in the mktime_utc function (#379) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/379 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | fix macosx CI (#480) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/480 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:28 +0000 Subject: [gnutls-devel] GnuTLS | resumption: curve is not stored in the resumed data (#331) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/331 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | Use of --enable-hardware-acceleration on Solaris/x86 leads to undefined symbols (#376) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/376 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:57 +0000 Subject: [gnutls-devel] GnuTLS | Replace AUTHORS with CODEOWNERS (#606) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/606 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:31 +0000 Subject: [gnutls-devel] GnuTLS | when I try to compile GnuTLS 3.5.18 with cryptodev support, it fails horribly (#405) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/405 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:36 +0000 Subject: [gnutls-devel] GnuTLS | lucky13-type of attack for SHA384 and SHA256 (#456) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/456 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:13:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:13:38 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS ignores the signature algorithms order when selecting certificate in TLSv1.3 (#501) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/501 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:28 +0000 Subject: [gnutls-devel] GnuTLS | document FIPS140-2 mode (#332) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/332 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | switch to nettle 3.4 API (#380) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/380 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:12:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:12:57 +0000 Subject: [gnutls-devel] GnuTLS | certtool creating authentication failures with TPM 1.2 when TPM SRK uses a password (#601) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/601 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:29 +0000 Subject: [gnutls-devel] GnuTLS | pcert API: missing function to load from file or URI (#373) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/373 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:28 +0000 Subject: [gnutls-devel] GnuTLS | "insecure algoritm" warning on self-signed certificates (independent of used algoritm) (#347) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/347 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:31 +0000 Subject: [gnutls-devel] GnuTLS | "constate: simplified allocation of epochs" breaks glib-networking tests (#426) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/426 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:14:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:14:30 +0000 Subject: [gnutls-devel] GnuTLS | Infinite loop when PIN is incorrect in pkcs11_login function (#425) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/425 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:24:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:24:04 +0000 Subject: [gnutls-devel] GnuTLS | session resumption: ability to limit resumption to TLS 1.3+ connections (#477) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- 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 Fri Nov 30 09:34:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:34:26 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_x509_crt_set_expiration_time: accepts GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (!828) References: Message-ID: New Merge Request !828 https://gitlab.com/gnutls/gnutls/merge_requests/828 Branches: tmp-well-defined-exp to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This modifies this function according to its documentation. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/828 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:34:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:34:37 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Reassigned Issue 609 https://gitlab.com/gnutls/gnutls/issues/609 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:36:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:36:31 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from bastl@eclipso.de): gnutls-3.5.18 (#445) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #445: https://gitlab.com/gnutls/gnutls/issues/445 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/445 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:37:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:37:23 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #575: https://gitlab.com/gnutls/gnutls/issues/575 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 09:38:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 08:38:45 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.6 (#634) References: Message-ID: New Issue was created. Issue 634: https://gitlab.com/gnutls/gnutls/issues/634 Author: Nikos Mavrogiannopoulos Assignee: The 3.6.6 release will be targetting stabilization of the TLS1.3 code base and as such there will be no new features which are not opt-in. Please switch the milestone of items you may work on to be included in that release to the 3.6.6 milestone. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 10:30:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 09:30:01 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_x509_crt_set_expiration_time: accepts GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (!828) In-Reply-To: References: Message-ID: Closing as the issue is different than the perceived. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/828#note_121315027 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 10:30:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 09:30:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_x509_crt_set_expiration_time: accepts GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (!828) In-Reply-To: References: Message-ID: Merge Request !828 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/828 Branches: tmp-well-defined-exp to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/828 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 10:30:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 09:30:52 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 10:33:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 09:33:40 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Reassigned Issue 609 https://gitlab.com/gnutls/gnutls/issues/609 Assignee changed from Nikos Mavrogiannopoulos to Unassigned -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 10:47:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 09:47:23 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.5 (#575) In-Reply-To: References: Message-ID: I've updated 3.6.x board to only include `3_6_x` issues. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/575#note_121320125 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:02:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:02:42 +0000 Subject: [gnutls-devel] GnuTLS | allow applications to specify non-crypto use of a hash algorithm (#352) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/352 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:03:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:03:21 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav I'm creating the last unit tests right now. At what time do you want to release? Do you think we can include it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121325078 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:03:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:03:23 +0000 Subject: [gnutls-devel] GnuTLS | allow applications to specify non-crypto use of a hash algorithm (#352) In-Reply-To: References: Message-ID: Milestone changed to gnutls improvements for applications ( https://gitlab.com/gnutls/gnutls/milestones/14 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/352 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:06:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:06:00 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-XTS mode (#354) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/354 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:28:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:28:02 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) In-Reply-To: References: Message-ID: Peter Wu commented on a discussion on lib/pkcs11.c: > len = p11_kit_space_strlen(str, str_max); > > if (len + 1 > *output_size) { > - *output_size = len + 1; That would be nice, but shouldn't `gnutls_pkcs11_obj_get_info` then be changed for consistency? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/827#note_121332508 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:33:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:33:08 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_pkcs11_token_get_info for short output buffers and fix a memleak (!827) In-Reply-To: References: Message-ID: > Would you like to introduce a unit test of the use of this flag? You can modify tests in tests/pkcs11/ or introduce a new one. A test for *all* supported flags would be nice, but due to #633 the resulting module name is empty for some reason. I have not figured out why. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/827#note_121334010 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:41:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:41:41 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: The time is 15.00 GMT but my focus is on another (non-public fix). If all the issues are addressed, I think we should postpone only the inclusion of `gnutls_certificate_get_rawpk_keypair` as it needs further discussion and I do not have time to get on it. So if you can make the deadline, move this part only to another MR. For all the others I think we are fine to include once the checklist is done, but please ping me when you are ready. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121336364 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:42:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:42:32 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Also make sure that this is rebased to latest master. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121336658 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 11:48:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 10:48:28 +0000 Subject: [gnutls-devel] GnuTLS | manpage generation: cleanup (!829) References: Message-ID: New Merge Request !829 https://gitlab.com/gnutls/gnutls/merge_requests/829 Project:Branches: GostCrypt/gnutls:fix-manpages to gnutls/gnutls:gnutls_3_5_x Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Backport b52735336857be24206e062b0a00501b1f0c597d to 3.5.x to fix #377. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality 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/829 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 13:46:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 12:46:26 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: All discussions on Merge Request !650 were resolved by Tom https://gitlab.com/gnutls/gnutls/merge_requests/650 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 15:52:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 14:52:40 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav I'm finished -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121411290 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 15:59:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 14:59:34 +0000 Subject: [gnutls-devel] GnuTLS | optional: add support for raw public keys under TLS1.3 (#280) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/280 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 15:59:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 14:59:40 +0000 Subject: [gnutls-devel] GnuTLS | Add support for TLS handshake with raw public keys (#26) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/26 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 16:15:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 15:15:43 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: I tried to verify whether the checklist above was done, but unfortunately there new issues. I would have fixed them myself, but I want to focus on the other issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121419461 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 16:16:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 15:16:51 +0000 Subject: [gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: What kind of issues? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_121419793 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 16:42:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 15:42:55 +0000 Subject: [gnutls-devel] GnuTLS | manpage generation: cleanup (!829) In-Reply-To: References: Message-ID: Debian failure seems to be related to openssl compatibility. Do we need to backport testsuite fixes to 3.5.x/3.3.x? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/829#note_121427999 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 17:11:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 16:11:54 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Signed (!830) References: Message-ID: New Merge Request !830 https://gitlab.com/gnutls/gnutls/merge_requests/830 Project:Branches: GostCrypt/gnutls:pkcs12-signed to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Support for signed data inside PKCS#12 files. Code has to be shared with PKCS#7. ## Checklist * [ ] 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/830 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 18:53:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 17:53:24 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PKCS11_TOKEN_MODNAME is unavailable when a provider is manually loaded (#633) In-Reply-To: References: Message-ID: I think I found the problem. `p11_kit_config_option(module, "module")` returns the value of the `module` option in the p11-kit configuration file. When autoloading is enabled, the module gains its name from the configuration file: ``` # /usr/share/p11-kit/modules/p11-kit-trust.module module: p11-kit-trust.so # /usr/share/p11-kit/modules/softhsm2.module module: /usr/lib/softhsm/libsofthsm2.so ``` When loading from file, of course no module configuration file is available. Proposal: - Add a new `GNUTLS_PKCS11_TOKEN_MODULE_NAME` type that returns the value of [p11_kit_module_get_name][1]. Examples: `p11-kit-trust` or `softhsm2` - Add a new `GNUTLS_PKCS11_TOKEN_MODULE_FILENAME` type that returns the value of [p11_kit_module_get_filename][2]. Examples: `/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so` or `/usr/lib/softhsm/libsofthsm2.so` - Deprecate the `GNUTLS_PKCS11_TOKEN_MODNAME` (and make it an alias of `GNUTLS_PKCS11_TOKEN_MODULE_NAME`). Reason for deprecation is because it has bugs (this one and the truncation and NULL crash issue fixed by !827). - (Add tests that check that all fields are NULL) Alternatively: - Keep the `GNUTLS_PKCS11_TOKEN_MODNAME` type which uses [p11_kit_module_get_name][1]. - Add a new `GNUTLS_PKCS11_TOKEN_MODPATH` type which uses [p11_kit_module_get_filename][2]. What do you think? This would likely be a continuation of !827 (it touches similar code). Should I add these changes to that PR? [1]: https://p11-glue.github.io/p11-glue/p11-kit/manual/p11-kit-Modules.html#p11-kit-module-get-name [2]: https://p11-glue.github.io/p11-glue/p11-kit/manual/p11-kit-Modules.html#p11-kit-module-get-filename -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/633#note_121461229 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:00:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:00:51 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: Hi. The problem is definitely in the server application. More specifically, in [udp-serv.c](https://gitlab.com/gnutls/gnutls/blob/master/src/udp-serv.c#L112), if the cookie is invalid, which it is for any non-CLIENT_HELLO message, then a HELLO_VERIFY_REQUEST message is constructed. A simple fix would be checking that the what is received is in fact a CLIENT_HELLO message. I am working on a reproducer, it's been a long time since I last programmed in C, so it should be interesting. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632#note_121471064 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:02:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:02:04 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) References: Message-ID: New Merge Request !831 https://gitlab.com/gnutls/gnutls/merge_requests/831 Project:Branches: simo5/gnutls:CVE_2018_16868 to gnutls/gnutls:master Author: Simo Sorce Assignee: This patchset implements mitigations for CVE-2018-16868 a Bleichenbacher-like attack that makes use of cache side-channel leakage. The mitigations are mostly implemented in Nettle, and GnuTLS has been changed to use a new side-channel silent fucntion exported from Nettle. Nettle >= 3.4.1 is now required. ## Checklist * [X] Code modified for security issue * [X] Test suite updated with functionality tests * [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/831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:02:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:02:23 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) 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/831#note_121471408 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:23:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:23:43 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.5 ( https://gitlab.com/gnutls/gnutls/milestones/17 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:27:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:27:26 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Reassigned Merge Request 831 https://gitlab.com/gnutls/gnutls/merge_requests/831 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:41:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:41:28 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on .gitlab-ci.yml: > FreeBSD.x86_64: > stage: stage1-testing > image: > + before_script: > + # CCache Config > + - mkdir -p cache > + - export CCACHE_BASEDIR=${PWD} > + - export CCACHE_DIR=${PWD}/cache > + - export CC="ccache gcc" this will fail, it needs to call clang here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121477262 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:43:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:43:23 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on .gitlab-ci.yml: > paths: > - cache/ > > -before_script: > - # CCache Config > - - mkdir -p cache > - - export CCACHE_BASEDIR=${PWD} > - - export CCACHE_DIR=${PWD}/cache > - - export CC="ccache gcc" > +.fedora_before_script: &fedora_before_script we don't need any fedora specific items as nettle 3.4.1 is already there; actually I'll try to move as much as possible to our CI once builds succeed. What's the best way to do that, would you give me access to your repo to change it, or you'll be online? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121477514 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:50:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:50:30 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on .gitlab-ci.yml: > FreeBSD.x86_64: > stage: stage1-testing > image: > + before_script: > + # CCache Config > + - mkdir -p cache > + - export CCACHE_BASEDIR=${PWD} > + - export CCACHE_DIR=${PWD}/cache > + - export CC="ccache gcc" ouch I thought I had changed it ... I will push once the othere results come true, so I can fix anything that is still broken besides FreeBSD -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121478490 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 20:51:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 19:51:48 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on .gitlab-ci.yml: > paths: > - cache/ > > -before_script: > - # CCache Config > - - mkdir -p cache > - - export CCACHE_BASEDIR=${PWD} > - - export CCACHE_DIR=${PWD}/cache > - - export CC="ccache gcc" > +.fedora_before_script: &fedora_before_script Review is fine by me, but if you prefer to do the changes I can give you access, I just need to find out how to do it :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121478640 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:03:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:03:25 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .gitlab-ci.yml: > paths: > - cache/ > > -before_script: > - # CCache Config > - - mkdir -p cache > - - export CCACHE_BASEDIR=${PWD} > - - export CCACHE_DIR=${PWD}/cache > - - export CC="ccache gcc" > +.fedora_before_script: &fedora_before_script Ok, try to remove all changes in .gitlab-ci.yml to download nettle, except the FreeBSD. I've included your scriptlet in the image creation. I'll try to do the same for the mingw images as well. https://gitlab.com/gnutls/build-images/pipelines/38556882 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121480132 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:05:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:05:33 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on .gitlab-ci.yml: > paths: > - cache/ > > -before_script: > - # CCache Config > - - mkdir -p cache > - - export CCACHE_BASEDIR=${PWD} > - - export CCACHE_DIR=${PWD}/cache > - - export CC="ccache gcc" > +.fedora_before_script: &fedora_before_script We need to remove it from Debian too ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121480409 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:07:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:07:43 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on .gitlab-ci.yml: > paths: > - cache/ > > -before_script: > - # CCache Config > - - mkdir -p cache > - - export CCACHE_BASEDIR=${PWD} > - - export CCACHE_DIR=${PWD}/cache > - - export CC="ccache gcc" > +.fedora_before_script: &fedora_before_script Oh cool, I'll trim the changes to be aonly about freebsd. Do I need to restore also the " only:\n - branches at gnutls/gnutls" part too ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121480666 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:20:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:20:31 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: yes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121482323 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:20:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:20:55 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Merging this will make gnutls 3.6.5 depend on an rc1 version of nettle :( -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121482366 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:23:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:23:23 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Why is that bad ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121482686 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:24:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:24:51 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Updated with the changes, only the freebsd CI is changed now, however it seems like freebsd is not running in CI ... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121482894 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:26:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:26:37 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: I canceled all but Debian builds as those have not changed at all, and running Debian ones just to make sure CI works there. By uncommenting the branches only for freebsd, that test is gone from CI ... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121483445 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:30:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:30:28 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: ouch yes, the freebsd CI runs only from the main repo. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121483884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:31:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:31:23 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: >> Merging this will make gnutls 3.6.5 depend on an rc1 version of nettle :( > Why is that bad ? It has tons of tls1.3 fixes, and I'm not sure many OSes will be eager to bring an rc version of nettle. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121484006 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:34:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:34:18 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Ok, about the freebsd CI, you can now run it, but you need to work in the main gnutls repo, not in a fork. Name the branch 'tmp-fix-cve-xxx' and push there and create a new MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121484668 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:36:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:36:55 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Ok I can push it there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121484969 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:39:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:39:55 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: About Nettle's RC1, it is basically just the security fix + some minor bugfixes, it's not a huge release or anything. Niels might have released it directly as 3.4.1 I think, but he is being overly cautious. I do not think it is a problem for vendors if they simply take the time to do a git log/git diff and see what's in it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121485296 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:46:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:46:40 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: I pushed to a tmp branch on master, however all Debian builds failed on my tree, maybe a bug in the generation of the images ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121486291 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:47:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:47:23 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: this? https://gitlab.com/gnutls/gnutls/pipelines/38560420 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121486443 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:48:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:48:34 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: only freebsd is failed up to now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121486590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:51:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:51:28 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Nope this: https://gitlab.com/simo5/gnutls/pipelines/38559102 The FreeBSD thing ... is th script running as non root there ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121486919 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:52:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:52:43 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: yes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121487069 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:53:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:53:48 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Then more wizardry is needed to get that one going ... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121487219 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:56:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:56:44 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: we use config.cache and if you change the options in configure it may fail. That's what you may be seeing in your repo. You can clean these caches or change the cache key name in .gitlab-ci.yml. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121487584 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:57:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:57:19 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: should we close this MR for the next one? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121487658 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 21:59:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 20:59:12 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Next one ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121487888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:00:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:00:59 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: I didn't change any options in configure, that's why it is suspicious. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121488162 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:02:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:02:54 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: next one = the branch you have created in the gnutls repo -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121488380 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:03:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:03:15 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: (to create a new MR from the branch to master) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121488414 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:05:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:05:11 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: either way works for me -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121488646 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:07:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:07:52 +0000 Subject: [gnutls-devel] GnuTLS | Add support for TLS handshake with raw public keys (#26) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/26 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:07:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:07:57 +0000 Subject: [gnutls-devel] GnuTLS | optional: add support for raw public keys under TLS1.3 (#280) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/280 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:17:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:17:31 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: Merge Request !831 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/831 Project:Branches: simo5/gnutls:CVE_2018_16868 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/831 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:17:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:17:30 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: ok, let's close this one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121489949 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:21:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:21:10 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!832) References: Message-ID: New Merge Request !832 https://gitlab.com/gnutls/gnutls/merge_requests/832 Branches: tmp-fix-CVE-2018-16868 to master Author: Simo Sorce Assignee: Nikos Mavrogiannopoulos Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This patchset implements mitigations for CVE-2018-16868 a Bleichenbacher-like attack that makes use of cache side-channel leakage. The mitigations are mostly implemented in Nettle, and GnuTLS has been changed to use a new side-channel silent fucntion exported from Nettle. Nettle >= 3.4.1 is now required. Paper describing the attack: http://www.wisdom.weizmann.ac.il/~eyalro/project/cat/cat.pdf Resolves #630 ## Checklist * [X] Code modified for security issue * [X] Test suite updated with functionality tests * [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/832 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Nov 30 22:22:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 30 Nov 2018 21:22:39 +0000 Subject: [gnutls-devel] GnuTLS | CVE-2018-16868 (!831) In-Reply-To: References: Message-ID: !832 replaces this one -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/831#note_121490509 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: