From gnutls-devel at lists.gnutls.org Fri Feb 1 12:03:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 11:03:47 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: @airtower\-luna the retrying comes from the gnutls. the problem was that the pull function was returning always -1 and EAGAIN because, by mistake, it was not clear to me how to pass data to the library so no data was passed. really is not clear from the docs. and i could not find official example... :S :( @vcunat that's a nice example. thank you for it. i wish i could have spotted it earlier. now I got handshake working. what is not nice is that i have to keep state for the handshake process in my application which i expected to be transparent (as in openssl). am i missing something here or is really like that? Same question for shutdown/bye? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_137411060 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 16:02:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 15:02:50 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on lib/ext/record_size_limit.c: > > - /* we do not want to accept sizes less than our minimum */ > - if (new_size < MIN_RECORD_SIZE) > - return 0; > + session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_RECEIVED; > > - /* if a record size larger than user specified maximum, ignore it */ > - if (new_size > session->security_parameters.max_record_send_size) > - return 0; > + /* we do not want to accept sizes outside of our supported range */ > + if (new_size < MIN_RECORD_SIZE) { > + /* for server, reject it by omitting the extension in the reply */ > + if (session->security_parameters.entity == GNUTLS_SERVER) > + return gnutls_assert_val(0); > + else > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); the server is not behaving incorrectly here, so at the very least, it feels to me like gnutls should log *why* it's rejecting it - I don't think the illegal_parameter is sufficient here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137509153 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 16:07:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 15:07:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on lib/ext/record_size_limit.c: > + /* we do not want to accept sizes outside of our supported range */ > + if (new_size < MIN_RECORD_SIZE) { > + /* for server, reject it by omitting the extension in the reply */ > + if (session->security_parameters.entity == GNUTLS_SERVER) > + return gnutls_assert_val(0); > + else > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + } > > session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > > - session->security_parameters.max_record_recv_size = new_size; > + _gnutls_handshake_log("EXT[%p]: record_size_limit %u negotiated\n", > + session, (unsigned)new_size); > + > + session->security_parameters.max_record_recv_size = the record layer code is applying the size only for the encrypted records, not right away? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137511314 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 17:03:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 16:03:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on lib/ext/record_size_limit.c: > if (new_size < 64) > return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > > + /* the same size should be requested upon HRR */ > + if (unlikely > + (session->internals.hsk_flags & HSK_HRR_SENT && > + session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_RECEIVED && > + new_size != session->internals.peer_record_size_limit)) > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); will that catch the situation when the extension was added or removed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137535103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 17:24:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 16:24:21 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on lib/ext/max_record.c: > } else { /* server side */ > > + if (session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_SENT) > + return 0; > + > if (session->security_parameters.max_record_recv_size != > DEFAULT_MAX_RECORD_SIZE) { > ret = _gnutls_mre_record2num > (session->security_parameters. > max_record_recv_size); > - > - /* it's not an error, as long as we send the > - * record_size_limit extension with that value */ > if (ret < 0) > - return 0; > + return gnutls_assert_val(ret); I've actually went and implemented it: https://github.com/tomato42/tlsfuzzer/pull/506 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137542320 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 17:25:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 16:25:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < 64) > return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > > + /* the same size should be requested upon HRR */ > + if (unlikely > + (session->internals.hsk_flags & HSK_HRR_SENT && > + session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_RECEIVED && > + new_size != session->internals.peer_record_size_limit)) > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); I've added test cases to check for that, please verify: https://github.com/tomato42/tlsfuzzer/pull/506 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137542588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 17:31:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 16:31:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: r- for the whole MR, see individual comments above also, please check the new tlsfuzzer PR and update to it after it is merged -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137544690 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 17:34:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 16:34:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: side note: if you have any ideas for the test coverage of `max_fragment_length` and possible interactions with `max_fragment_length`, please add comments to [tomato42/tlsfuzzer#505](https://github.com/tomato42/tlsfuzzer/issues/505) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137545824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 22:54:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 21:54:52 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) References: Message-ID: New Issue was created. Issue 689: https://gitlab.com/gnutls/gnutls/issues/689 Author: David Benjamin Assignee: ## Description of problem: GnuTLS sends the downgrade sentinel at TLS 1.3. Per RFC 8446, it should only be sent at TLS 1.2 or earlier. https://tools.ietf.org/html/rfc8446#section-4.1.3 Skimming `handshake.c`, the issue appears to be that `_gnutls_gen_server_random` is called very early, before the `supported_versions` extension is parsed. ## Version of gnutls used: master branch. Also reproduced in 3.6.5. ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) compiled from source ## How reproducible: Steps to Reproduce: * `gnutls-serv -p 4433 -a --x509certfile ./doc/credentials/x509/cert-rsa.pem --x509keyfile ./doc/credentials/x509/key-rsa.pem` * `openssl s_client -connect localhost:4433 -debug` with OpenSSL 1.1.1 or later * Look for the first block of "read from " lines, to find the ServerHello * Check the rest of the output to confirm TLS 1.3 was negotiated ## Actual results: The ServerHello contains the string "DOWNGRD" in the printable hex dump (it's split over two rows), which is (most of) the TLS 1.3 downgrade sentinel. ## Expected results: The TLS 1.3 downgrade sentinel is not present. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 1 23:22:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 01 Feb 2019 22:22:02 +0000 Subject: [gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690) References: Message-ID: New Issue was created. Issue 690: https://gitlab.com/gnutls/gnutls/issues/690 Author: David Benjamin Assignee: ## Description of problem: GnuTLS appears to have logic to look at the key usage bits and filter the cipher suite in TLS 1.2, but it doesn't do the same in TLS 1.3, where the only operations are sign-only. The result is that callers who accidentally created an encryption-only RSA key silently (though not ideally since it uses a plain RSA cipher) worked at TLS 1.2, but, once upgrading to a newer GnuTLS, break at TLS 1.3. See also: https://github.com/apple/cups/issues/5506 ## Version of gnutls used: master branch ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) built from source ## How reproducible: Steps to Reproduce: * Save the following as `enc-only-cert.pem`: ``` -----BEGIN CERTIFICATE----- MIICzzCCAbegAwIBAgIRALllB5+ixBXbLJKkHn9ofl4wDQYJKoZIhvcNAQELBQAw EjEQMA4GA1UEChMHQWNtZSBDbzAeFw0xOTAyMDEyMjAwMDNaFw0xOTAyMDEyMjAw MDNaMBIxEDAOBgNVBAoTB0FjbWUgQ28wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC6C9qEGRIBQXV8Lj29vVu+U+tyXzSSinWIumK5ijPhCm3DLnv4Rayx kFwemtnkGRZ/o94ZnsXkBfU/IlsYdkuq8wK9WI/ql3gwWjH+KARIhIQcSLGiJcLN 6kGuG2nlRBKMcPgPiEq2B0yBXFf4tG3CBbeae7+8G7uvOmv8NLyKj32neWpnUCTL 5o2VwyPoxjLxT5gUR69v9XSVFj2irCZbsEedeKSb++LqyMhLfnRTzNv+ZHNh4izZ HrktR25MvnT5QyBq32hx7AjZ2/xo70OmH7w10a2DwsVjJNMdxTEmgyvU9M6CeYRP X1Ykfg+sXCTtkTVAlBDUviIqY95CKy25AgMBAAGjIDAeMA4GA1UdDwEB/wQEAwIF IDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBfCc01lNWc68F9qHzt OZFquAps5KXiZXeXhHcYi7Xwk7AUwmX1LhDGkrZih6fPbM7uNXHqNKTEQwj8SDoo PFZ1EN3nbgjE7gV451xOcCeS+kW7poCeU7JWmdKgt4iL1SMJMjXtBIKbsp91YKLs HOUE6jYtLDyZ/Qk+kZBW8YbLIly937oott7yr7nXMWPNpOgiECAmSHUvzB1fSSuJ Mw4lx3sgVwxjCaQExKocKokFKB6oooO8DMmc9VD6MNOMY1Pv9Mrutb3KsmymjLdW RjNl0DVpWZxgWoJMAXOkowlwlEh+CCEXeVXGs/tD5Amtacg9M/b3pIONmciojCrx DvYB -----END CERTIFICATE----- ``` * Save the following as `enc-only-key.pem`. ``` -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC6C9qEGRIBQXV8 Lj29vVu+U+tyXzSSinWIumK5ijPhCm3DLnv4RayxkFwemtnkGRZ/o94ZnsXkBfU/ IlsYdkuq8wK9WI/ql3gwWjH+KARIhIQcSLGiJcLN6kGuG2nlRBKMcPgPiEq2B0yB XFf4tG3CBbeae7+8G7uvOmv8NLyKj32neWpnUCTL5o2VwyPoxjLxT5gUR69v9XSV Fj2irCZbsEedeKSb++LqyMhLfnRTzNv+ZHNh4izZHrktR25MvnT5QyBq32hx7AjZ 2/xo70OmH7w10a2DwsVjJNMdxTEmgyvU9M6CeYRPX1Ykfg+sXCTtkTVAlBDUviIq Y95CKy25AgMBAAECggEAHPvvxRiqx2tNRFVn5QF1I4erbJwMcrADc5OmAcXYIz0e sIOzaJBiQR9+Wn5BZ9nIuYXr+g3UQpvzAyz1CDCVxUIqsRj1AtUqMk4675+IW0vZ 0RY6Jkq/uJjANsGqk78xLJQE8VaIXSdx8c1THznsx4dgfT6+Ni4T5U6yuA33OZaw 4NdYZYtEkqNiqK6VYe4mAxxVh5qscihVVMGkBVqJNiiEotctm1lph8ow+7o8ggXO W9xm+RHHPcH7Epx7hjkb/helANcYOK950W5/R+2zWV9R6kxo6R+/hfGFFmCvl4k5 +i8Y0IlEv3fze1E0Lwyf379i3C/cKcuaE5gwR54BAQKBgQDxlsNy9M37HgguglHt 8W+cuPNtxNjFCWIjNR9dSvdr1Oi28Z1AY+BBPSv6UBKnT5PpOFjqxfMY/j/zoKdI aYX1phgeQHXcHrB1pS8yoaF/pTJSN2Yb8v9kl/Ch1yeYXaNVGmeBLkH9H6wIcUxD Mas1i8VUzshzhcluCNGoJj9wUQKBgQDFJOoWncssfWCrsuDWEoeU71Zh3+bD96GF s29CdIbHpcbxhWYjA9RM8yxbGPopexzoGcV1HX6j8E1s0xfYZJV23rxoM9Zj9l5D mZAJQPxYXIdu3h4PslhZLd3p+DEHjbsLC/avk3M4iZim1FMPBJMswKSL23ysqXoY /ynor+W06QKBgHYeu6M6NHgCYAe1ai+Hq4WaHFNgOohkJRqHv7USkVSkvb+s9LDl 5GChcx4pBmXNj8ko5rirXkerEEOjGgdaqMfJlOM9qyKb0rVCtYfw5RCPCcKPGZqy vdJGQ74tf0uNBO34QgE0R8lmMevS0XHNGCPPGgV0MSfikvD82N15De1xAoGAbsZM RsMJfAlDPZc4oPEuf/BwMHTYPTsy5map2MSTSzGKdQHJH1myfD6TqOiDALXtyzlX 63PUShfn2YNPvcbe+Tk00rR1/htcYk2yUpDSenAbpZ9ncth6rjmInURZgG4SMKXb SlLnBljCjtN1jFW8wQPKMc/14SslsVAHY3ka8KkCgYB58QNT1YfH3jS62+mT2pXq qLjLqvsD742VYnFoHR+HBOnN8ry0dda4lgwM106L5FgSg9DOZvASZ+QGFk+QVQv+ c77ASWpuhmBmamZCrwZXrq9Xc92RDPkKFqnP9MVv06hYKNp0moSdM8dIaM6uSows /r/aDs4oudubz26o5GDKmA== -----END PRIVATE KEY----- ``` * `gnutls-serv -p 4433 -a --x509certfile enc-only-cert.pem --x509keyfile enc-only-key.pem` * Build BoringSSL from source. Then run the command-line testing tool: * `bssl client -connect localhost:4433 -max-version tls1.3` * `bssl client -connect localhost:4433 -max-version tls1.2` ## Actual results: The first `bssl` run fails with `KEY_USAGE_BIT_INCORRECT`. The second `bssl` run succeeds but negotiates `TLS_RSA_WITH_AES_128_GCM_SHA256` ## Expected results: It's unclear how feasible this is or how well it fits with the rest of what GnuTLS does, but given that you all already filter the cipher list based on key usage (otherwise presumably `gnutls-serv` would have negotiated ECDHE_RSA), it seemed odd that you don't also take it into consideration for TLS 1.3. Then again, versions are usually negotiated fairly early, so you may consider it a WontFix. Anyway, I thought I would bring this up in case you wished to do anything about it. A footnote: BoringSSL doesn't currently enforce the key usage extension at TLS 1.2 yet, though we're [working on changing that](https://crbug.com/795089). We do enforce it at TLS 1.3 as there were no risks with antivirus and bad Enterprise deployments. Though that's moot here since GnuTLS's behavior at TLS 1.2 *does* satisfy the key usage extension. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690 You're receiving 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 Feb 2 07:12:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 06:12:30 +0000 Subject: [gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690) In-Reply-To: References: Message-ID: Reassigned Issue 690 https://gitlab.com/gnutls/gnutls/issues/690 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690 You're receiving 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 Feb 2 07:12:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 06:12:55 +0000 Subject: [gnutls-devel] GnuTLS | WIP: When negotiating TLS1.3 enforce certificate key usage (!902) References: Message-ID: New Merge Request !902 https://gitlab.com/gnutls/gnutls/merge_requests/902 Branches: tmp-key-usage 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 Add a description of the new feature/bug fix. Reference any relevant bugs. ## 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/902 You're receiving 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 Feb 2 07:14:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 06:14:05 +0000 Subject: [gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690) In-Reply-To: References: Message-ID: Thank you for the report. Indeed gnutls should fail to sign with such a certificate here. Ideally we should fallback to TLS1.2 when no signing certificates are present. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690#note_137711043 You're receiving 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 Feb 2 08:45:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 07:45:10 +0000 Subject: [gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690 You're receiving 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 Feb 2 08:53:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 07:53:59 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689 You're receiving 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 Feb 2 15:36:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 14:36:04 +0000 Subject: [gnutls-devel] GnuTLS | build: pass NETTLE_LIBS together with HOGWEED_LIBS (!903) References: Message-ID: New Merge Request !903 https://gitlab.com/gnutls/gnutls/merge_requests/903 Project:Branches: GostCrypt/gnutls:fix-nettle-check 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 * [ ] 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/903 You're receiving 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 Feb 2 15:50:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 14:50:19 +0000 Subject: [gnutls-devel] GnuTLS | build: do not generate mech-list.h if p11-kit is not available (!904) References: Message-ID: New Merge Request !904 https://gitlab.com/gnutls/gnutls/merge_requests/904 Project:Branches: GostCrypt/gnutls:fix-pkcs11-mechs 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 * [ ] 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/904 You're receiving 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 Feb 2 17:40:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 16:40:52 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) In-Reply-To: References: Message-ID: @dwmw2 what is the status with the tpmkey uri? Should we use something internal to gnutls or there is interest for standardization? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594#note_137752369 You're receiving 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 Feb 2 17:55:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 16:55:39 +0000 Subject: [gnutls-devel] GnuTLS | build: do not generate mech-list.h if p11-kit is not available (!904) In-Reply-To: References: Message-ID: Merge Request !904 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/904 Project:Branches: GostCrypt/gnutls:fix-pkcs11-mechs 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/904 You're receiving 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 Feb 2 17:56:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 16:56:37 +0000 Subject: [gnutls-devel] GnuTLS | build: pass NETTLE_LIBS together with HOGWEED_LIBS (!903) In-Reply-To: References: Message-ID: Merge Request !903 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/903 Project:Branches: GostCrypt/gnutls:fix-nettle-check 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/903 You're receiving 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 Feb 2 22:55:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 02 Feb 2019 21:55:46 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) In-Reply-To: References: Message-ID: I believe there is interest, yes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594#note_137773111 You're receiving 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 Feb 3 03:08:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 02:08:41 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) References: Message-ID: New Issue was created. Issue 691: https://gitlab.com/gnutls/gnutls/issues/691 Author: Hubert Assignee: https://github.com/autoconf-archive/autoconf-archive/blob/master/NEWS https://github.com/curl/curl/pull/3499 https://github.com/curl/curl/issues/3497 https://github.com/jb-alvarado/media-autobuild_suite/issues/1058 Anybody around here got up-to-date autoconf-archive 2019.01.06 installed or do you guys simply don't ever bother updating your LX's? It's almost a month now, so would it'd be nice if this somehow could be fixed "in the near future"... Thanks! :thumbsup: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691 You're receiving 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 Feb 3 06:19:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 05:19:27 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: What incompatibility do you refer to? This report is a list of unrelated issues of other projects. Use the m4 shipped by gnutls if you have issues with the latest. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137786517 You're receiving 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 Feb 3 07:43:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 06:43:50 +0000 Subject: [gnutls-devel] GnuTLS | fastopen: only use connectx if available (!876) In-Reply-To: References: Message-ID: Would you like to update this MR with either code developed by you or ask permission to use it from the curl project (different license). Also there are multiple other failures in the CI due to this change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/876#note_137789024 You're receiving 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 Feb 3 07:45:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 06:45:17 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: I've commented on the other MR but here for reference too, I'm fine with that, though I think we should introduce some unit tests on the current behavior before we update this function. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_137789091 You're receiving 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 Feb 3 07:46:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 06:46:46 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) In-Reply-To: References: Message-ID: Do we have some agreement on the URI form which can allow brining that to gnutls? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594#note_137789141 You're receiving 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 Feb 3 18:29:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 17:29:26 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: The latest m4 shipped is [over a year](https://gitlab.com/gnutls/gnutls/blob/master/m4/ax_code_coverage.m4) old and the culprit here ... >What incompatibility do you refer to? The links I posted are for READING? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137830611 You're receiving 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 Feb 3 18:29:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 03 Feb 2019 17:29:26 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: Issue was closed by Hubert Issue #691: https://gitlab.com/gnutls/gnutls/issues/691 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 09:45:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 08:45:01 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: What exactly does GnuTLS has to do with the ISC license ? As your links show, curl has a problem with the LGPL license - GnuTLS doesn't have that issue. Our `ax_code_coverage.m4` is serial 25 - even Debian's (unstable) version is the same. I currently don't see any reason to update to a (pretty untested) new version. Except you give us a very good reason. Reading the discussion at https://github.com/jb-alvarado/media-autobuild_suite/issues/1058 doesn't help very much. The Q is why did the m4 file work for you so long and suddenly it doesn't any more ? At least here we can't reproduce (which doesn't say much if you are at bleeding edge). We are back now from FOSDEM and live is going on... Any yes, we are currently clueless. But your way of mixing things up and not explaining in detail isn't helpful at all. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137927443 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 10:13:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 09:13:02 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: >The Q is why did the m4 file work for you so long and suddenly it doesn't any more Already explained here: because of a new autoconf-archive 2019.01.06, published 4 weeks ago. That update came with msys2 update, if you don't have the new autoconf-archive then you should speak to your LX distro maintainers ... And apart from the license: it's [working again](https://github.com/jb-alvarado/media-autobuild_suite/pull/1073/commits/aae921e2b3d66a61293f6ac2eb0adff691e005b5) for [MABS](https://github.com/jb-alvarado/media-autobuild_suite), if --enable-code-coverage would be used all we would have to do would be installing lcov package and adding -lgcov to the .pc's Libs.private and that should be it. But we don't need CC, so problem is solved for use. You don't need to do anything if you don't want to, thanks :+1: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137938628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:00:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:00:46 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: So (apart from licensing) it is an msys2 issue. That's why our CI doesn't have an issue (yet). Windows is currently tested via MinGW32+64 Linux cross-compilation. If any Linux distro runs into an issue with `ax_code_coverage.m4` they update it. No need to ping them. But anyways, I just tested the 2019.01.06 version without issues here. So there is nothing blocking an update for GnuTLS. But as you might recognize, this is a (small) community project that lives from contributions. One of the most helpful ones are issues with an detailed and understandable description that makes the issue reproducible for us. And "helpful" also means helpful to you and others who run into the same problem (maybe just a bit later). Closing an issue just because someone is clueless in the first place isn't a helpful action. Ranting somewhere else (https://github.com/jb-alvarado/media-autobuild_suite/issues/1058#issuecomment-460071196) isn't also very helpful, it just shows a certain degree of social incompetence (but maybe you feel better when doing so). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137957017 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:12:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:12:47 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) References: Message-ID: New Merge Request !905 https://gitlab.com/gnutls/gnutls/merge_requests/905 Branches: tmp-update-ax-code-coverage 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 Update m4/ax_code_coverage.m4 to latest version from http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4 ## 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/905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:17:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:17:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) References: Message-ID: New Merge Request !906 https://gitlab.com/gnutls/gnutls/merge_requests/906 Branches: tmp-fix-uninitialized2 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 Includes code cleanup. This MR replaces !897. ## 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/906 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:18:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:18:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Merge Request !897 was closed by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/897 Branches: tmp-fix-uninitialized to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:18:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:18:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Closing this in favor of !906 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_137964344 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 11:33:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 10:33:39 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: Look, I was told to "Use the m4 shipped by gnutls" which we did ALL THE TIME and which errors with [gnutls make fails: missing separator in Makefile line 2042](https://github.com/jb-alvarado/media-autobuild_suite/issues/1058) and I got "What incompatibility do you refer to?" instead. So that's also lazy and not just clueless then, downloading the error logs would've helped as well and actually READ THEM. At least someone else gave me a thumbs up here so there must be more to it ... Anyway, don't change your m4 file, you can sit on it as much as you want, curl team got the message, they analyzed it and found their own way, even got rid of it. And as for MABS there's only harfbuzz team using the old m4 file (same checksum wherever you two got it from) but there's no problem with that so far. So like I said: we're done. "maybe you feel better when doing so" Yes I do. Because developers developing for ALL platforms should test on ALL platforms, shouldn't they? But today the customer is the banana, in Germany we call this "skill shortage" (for Micro$oft it's normal, only idiots work there, no quality control at all, oh sorry GH is M$ now, I hope it doesn't get worse then???). Oh no, please don't go and install mingw now, to check if gnutls with old m4 still works there or not with NEW autoconf-archive. I don't want to "demand" too much of you! So TTYL have a good day! :+1: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_137970916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 12:40:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 11:40:32 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: CI failure due to missing m4 dependencies (found in autoconf-archive, e.g. `ax_add_am_macro_static.m4`). We have to update our CI runners and add `autoconf-archive` as dependency to README.md. If we do so, we can also remove `ax_code_coverage.m4` from our repo. Not maintaining our own version means less work. @nmav WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_137998538 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 12:43:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 11:43:10 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Thinking about it... since the new version of `ax_code_coverage.m4` needs changes in `Makefile.am` that are incompatible with current downstream versions, we might run into a problem... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_137999404 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:11:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:11:34 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: I was tweaking with coverage builds few weeks ago, and I have a patch for it at home. Should I try to revive it? About moving to `autoconf-archive` latest version by default, I do not know. Seeing the breakage for `ax_code_coverage` it may add quite some overhead to keep up with it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138030706 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:11:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:11:57 +0000 Subject: [gnutls-devel] GnuTLS | build: do not generate mech-list.h if p11-kit is not available (!904) In-Reply-To: References: Message-ID: Merge Request !904 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/904 Project:Branches: GostCrypt/gnutls:fix-pkcs11-mechs 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/904 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:13:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:13:27 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4 is not license compatible and must not be used / ax_code_coverage.m4 conflicts with ISC license (#691) In-Reply-To: References: Message-ID: I think that's an example of issues we should be closing with an explanation of being unhelpful. @schmidthubert this is not a reading list, not a group to address _your_ issues. If you want others to fix your problems, try to be helpful. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/691#note_138031371 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:16:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:16:12 +0000 Subject: [gnutls-devel] GnuTLS | build: pass NETTLE_LIBS together with HOGWEED_LIBS (!903) In-Reply-To: References: Message-ID: Merge Request !903 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/903 Project:Branches: GostCrypt/gnutls:fix-nettle-check 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/903 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:21:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:21:57 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on fuzz/get_all_corpora: > -#!/bin/sh -eu > +#!/bin/sh -u Not on this script but I saw this error when running `get_ossfuzz_corpora`: ``` $ ./get_ossfuzz_corpora ./get_ossfuzz_corpora: line 10: $1: unbound variable ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_138034224 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:22:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:22:21 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: All discussions on Merge Request !883 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/883 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:26:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:26:19 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Would it be possible to add 1-2 lines about this script in fuzz/README.md? One reason is for me to understand what it does in order to review, and another is not to lose that information. Is my understanding correct that this script downloads the latest corpora from oss-fuzz to replace our included corpora? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_138035796 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 14:42:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 13:42:18 +0000 Subject: [gnutls-devel] GnuTLS | Update to new ax_code_coverage.m4 (!907) References: Message-ID: New Merge Request !907 https://gitlab.com/gnutls/gnutls/merge_requests/907 Project:Branches: schmidthubert/gnutls:code-coverage-rules to gnutls/gnutls:master Author: Hubert Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. Fixes https://gitlab.com/gnutls/gnutls/issues/691 Tested with autoconf-archive 2018.03.13-1 and 2019.01.06-1 ## 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/907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:00:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:00:54 +0000 Subject: [gnutls-devel] GnuTLS | Update to new ax_code_coverage.m4 (!907) In-Reply-To: References: Message-ID: Merge Request !907 was closed by Hubert Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/907 Project:Branches: schmidthubert/gnutls:code-coverage-rules to gnutls/gnutls:master Author: Hubert Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/907 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:29 +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: Issue was closed by Nikos Mavrogiannopoulos Issue #608: https://gitlab.com/gnutls/gnutls/issues/608 -- 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 Feb 4 15:03:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:32 +0000 Subject: [gnutls-devel] GnuTLS | Support PKCS 7 decryption (#152) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #152: https://gitlab.com/gnutls/gnutls/issues/152 -- 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 Mon Feb 4 15:03:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:36 +0000 Subject: [gnutls-devel] GnuTLS | no DTLS stream identification (#110) In-Reply-To: References: Message-ID: @nmav This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/110#note_138049476 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:36 +0000 Subject: [gnutls-devel] GnuTLS | no DTLS stream identification (#110) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #110: https://gitlab.com/gnutls/gnutls/issues/110 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/110 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:31 +0000 Subject: [gnutls-devel] GnuTLS | Support PKCS 7 decryption (#152) In-Reply-To: References: Message-ID: @lumag This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/152#note_138049437 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:41 +0000 Subject: [gnutls-devel] GnuTLS | Provide a multiplexer (#38) In-Reply-To: References: Message-ID: @nmav This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/38#note_138049524 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:29 +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: @Vrancken This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/608#note_138049419 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:40 +0000 Subject: [gnutls-devel] GnuTLS | Support Service Name expression for Subject Alt Name (#51) In-Reply-To: References: Message-ID: @dkg This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/51#note_138049506 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:34 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_get_peers may return an unsorted chain (#116) In-Reply-To: References: Message-ID: @nmav This issue was marked as needinfo with no update for long time. We are now closing it, but please re-open if it is still relevant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/116#note_138049461 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:40 +0000 Subject: [gnutls-devel] GnuTLS | Support Service Name expression for Subject Alt Name (#51) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #51: https://gitlab.com/gnutls/gnutls/issues/51 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/51 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:35 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_get_peers may return an unsorted chain (#116) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #116: https://gitlab.com/gnutls/gnutls/issues/116 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/116 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:03:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:03:42 +0000 Subject: [gnutls-devel] GnuTLS | Provide a multiplexer (#38) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #38: https://gitlab.com/gnutls/gnutls/issues/38 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/38 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:05:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:05:32 +0000 Subject: [gnutls-devel] GnuTLS | Issues require labels (#692) References: Message-ID: New Issue was created. Issue 692: https://gitlab.com/gnutls/gnutls/issues/692 Author: Nikos Mavrogiannopoulos Assignee: The following issues require labels: - [ ] [Improving speed of test suite](https://gitlab.com/gnutls/gnutls/issues/674) Please take care of them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/692 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:05:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:05:55 +0000 Subject: [gnutls-devel] GnuTLS | Improving speed of test suite (#674) In-Reply-To: References: Message-ID: @rockdaboot This issue is unlabelled after 15 days. It needs attention. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/674#note_138050245 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:06:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:06:56 +0000 Subject: [gnutls-devel] GnuTLS | Issues require labels (#692) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #692: https://gitlab.com/gnutls/gnutls/issues/692 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/692 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:07:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:56 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Signed PKCS#12 support (!830) In-Reply-To: References: Message-ID: @lumag This merge request is marked as work in progress with no update for very long time. We are now closing it, but please re-open if you are still interested in finishing this merge request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/830#note_138051416 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:07:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:58 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Merge Request !796 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/796 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_601 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/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 Feb 4 15:08:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:08:02 +0000 Subject: [gnutls-devel] GnuTLS | WIP: GOST cryptography support (!133) In-Reply-To: References: Message-ID: @lumag This merge request is marked as work in progress with no update for very long time. We are now closing it, but please re-open if you are still interested in finishing this merge request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/133#note_138051441 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:07:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:56 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Signed PKCS#12 support (!830) In-Reply-To: References: Message-ID: Merge Request !830 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/830 Project:Branches: GostCrypt/gnutls:pkcs12-signed 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/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 Mon Feb 4 15:07:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: @smuellerDD This merge request is marked as work in progress with no update for very long time. We are now closing it, but please re-open if you are still interested in finishing this merge request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_138051431 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:08:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:08:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: GOST cryptography support (!133) In-Reply-To: References: Message-ID: Merge Request !133 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/133 Project:Branches: GostCrypt/gnutls:gost-review 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/133 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:07:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:58 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: @stefanberger This merge request is marked as work in progress with no update for very long time. We are now closing it, but please re-open if you are still interested in finishing this merge request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_138051426 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:07:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:07:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Merge Request !555 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/555 Project:Branches: smuellerDD/gnutls:afalg 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/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 Mon Feb 4 15:09:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Signed PKCS#12 support (!830) In-Reply-To: References: Message-ID: This was a test of a gitlab triage policy. Reopening. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/830#note_138051868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:09:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:09 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: This was a test of a gitlab triage policy. Reopening. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_138051916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:09:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:09 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Merge Request !555 was reopened by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/555 Project:Branches: smuellerDD/gnutls:afalg 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/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 Mon Feb 4 15:09:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: This was a test of a gitlab triage policy. Reopening. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/796#note_138051989 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:09:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:02 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Signed PKCS#12 support (!830) In-Reply-To: References: Message-ID: Merge Request !830 was reopened by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/830 Project:Branches: GostCrypt/gnutls:pkcs12-signed 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/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 Mon Feb 4 15:09:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:09:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: tpm: Try to use password from the PIN callback if srk_password is NULL (!796) In-Reply-To: References: Message-ID: Merge Request !796 was reopened by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/796 Project:Branches: stefanberger/gnutls:tpm12_fixes_issue_601 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/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 Feb 4 15:10:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:10:27 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: The main issue is that `our m4/ax_code_coverage.m4` gets overwritten during `./bootstrap`: ``` aclocal: overwriting 'm4/ax_code_coverage.m4' with '/usr/share/aclocal/ax_code_coverage.m4' ``` In our CI images there is no `autoconf-archive`, so the file doesn't get overwritten. And even if we install `autoconf-archive`, `ax_code_coverage.m4` is compatible or identical (version 25) in Fedora and Debian images. The new 2019 version 33 of `ax_code_coverage.m4` needs other macros from `autoconf-archive`. So if we that file in our repo, we also need a 2019 version of `autoconf-archive` due to the above mentioned overwriting. I currently don't know how to prevent the overwriting. If we can solve that, we could possibly have code like this in configure.ac: ``` m4_ifdef([CODE_COVERAGE_RULES], [], [ CODE_COVERAGE_RULES = "include $(top_srcdir)/aminclude_static.am" AC_SUBST([CODE_COVERAGE_RULES]) ]) ``` and leave `Makefile.am` as is. Any idea ? What does your patch look like ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138052341 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:06:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:06:55 +0000 Subject: [gnutls-devel] GnuTLS | Issues require labels (#692) In-Reply-To: References: Message-ID: This was a test of the gitlab-triage bot. Closing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/692#note_138050594 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:14:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:14:41 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) References: Message-ID: New Merge Request !908 https://gitlab.com/gnutls/gnutls/merge_requests/908 Branches: tmp-gitlab-triage 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 Based on our discussion in Brussels, this is a proposal to add a set of policies regarding issues and merge requests to be enforced by the gitlab-triage bot. That is: - Issues without any label for more than a month are marked with needs attention label - Issues with needinfo label are closed if they are not updated within a month - Merge requests marked as WIP with no update within 5 months are closed. These rules are not enforced automatically; we have to schedule a run of the gitlab-triage bot. ## 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/908 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:42:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:42:05 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: LGTM. We can change the timers at any time, if something is not as expected. I suggest a daily check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908#note_138064710 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 15:50:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 14:50:19 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Suggestion: We keep the old `ax_code_coverage.m4` in the repo. It works on systems without `autoconf-archive` installed. With a 2018 `autoreconf-archive` (or older), this also works. With a 2019 `autoreconf-archive` installed, the above code in configure.ac rushes in and `@CODE_COVERAGE_RULES` in `Makefile.am` becomes substituted. I can't currently test it (in lack of a system with 2019 `autoreconf-archive`). Q: why isn't the new version of `ax_code_coverage.m4` backwards-compatible when it is so easy !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138068914 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 17:08:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 16:08:52 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Testing with latest release of autoconf-archive gives me ``` $ make aminclude_static.am:45: *** missing separator. Stop. ``` Not sure why, but the auto-generated `aminclude_static.am` is buggy. My test was installing autoconf-archive from https://mirrors.ocf.berkeley.edu/gnu/autoconf-archive/autoconf-archive-2019.01.06.tar.xz, ./configure, sudo make install (install it to /usr/local/share/aclocal). Then testing with `autoreconf -fi -I /usr/local/share/aclocal && ./configure --enable-code-coverage --disable-doc` and the following code in configure.ac (and all kinds of deviations): ``` m4_ifndef([CODE_COVERAGE_RULES], [ [CODE_COVERAGE_RULES='include $(top_srcdir)/aminclude_static.am'] AC_SUBST([CODE_COVERAGE_RULES]) m4_ifdef([_AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE([CODE_COVERAGE_RULES])]) ]) ``` `Makefile` looks good then, but `aminclude_static.am` has that bug. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138096748 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 18:21:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 17:21:46 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: There have been several changes since serial 32 it's 33 now, also there's this: https://github.com/autoconf-archive/autoconf-archive/pull/182 which has https://github.com/tpm2-software/tpm2-abrmd/commit/3cacba40114f26650c681b067ff0495f4a0dd186 from 7 days ago calling it an "update to ax_code_coverage.m4 version 2019.01.06" build: update for ax_code_coverage.m4 version 2019.01.06 @CODE_COVERAGE_RULES@ doesn't exist any more and needs to be replaced. Also includes a compatibility wrapper for older versions of the file. There is a bug in the new version of ax_code_coverage.m4 (cf. autoconf-archive/autoconf-archive#182): AM_DISTCHECK_CONFIGURE_FLAGS is recursively defined, which causes "make distcheck" to fail in combination with --enable-code-coverage. This is fixed by overwriting the faulty definition. Signed-off-by: Jonas Witschel master (#574) 2.1.0_rc2 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138127753 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 19:08:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 18:08:05 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4: updated to latest macro (!909) References: Message-ID: New Merge Request !909 https://gitlab.com/gnutls/gnutls/merge_requests/909 Branches: tmp-code-coverage-update 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 updates the `ax_code_coverage.m4` to the latest macro version. ## 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/909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 19:08:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 18:08:26 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: I moved the code I had in !909 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138138918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 20:51:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 19:51:27 +0000 Subject: [gnutls-devel] GnuTLS | Valid CA certificate rejected by GnuTLS (#693) References: Message-ID: New Issue was created. Issue 693: https://gitlab.com/gnutls/gnutls/issues/693 Author: Tavis Ormandy Assignee: ## Description of problem: The routine gnutls_certificate_set_x509_trust_file() fails if the valid certificate [SSL Blindado PRO EV](https://crt.sh/?q=d6dc2aaea926ff94854e7d3eb310c6349714e8e6) is in the specified file. ## Version of gnutls used: gnutls-3.6.6.tar.xz ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Built from source. ## How reproducible: Steps to Reproduce: * Compile this program: ``` #include #include #include int main(int argc, char **argv) { gnutls_certificate_credentials_t cred; int count; gnutls_global_init(); gnutls_certificate_allocate_credentials(&cred); count = gnutls_certificate_set_x509_trust_file(cred, "cafile.pem", GNUTLS_X509_FMT_PEM); fprintf(stderr, "GnuTLS processed %d roots\n", count); gnutls_certificate_free_credentials(cred); return 0; } ``` `$ gcc $(pkg-config --cflags --libs gnutls) testcase.c` * Download the certificate: `$ wget -O cafile.pem https://crt.sh/?d=12730101` * Observe error code: `$ ./a.out` ## Actual results: ``` $ ./a.out GnuTLS processed -43 roots ``` ## Expected results: ``` $ ./a.out GnuTLS processed 1 roots ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/693 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 21:09:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 20:09:32 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) In-Reply-To: References: Message-ID: actually I thought that that was handled by tlsfuzzer already, but there was a bug that stopped it from checking the value for TLS 1.3 ServerHello's, this PR should make the test case actually do what we expected it to do already: https://github.com/tomato42/tlsfuzzer/pull/507 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689#note_138162787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 21:11:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 20:11:58 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: @schmidthubert Thanks for detailed info. I already see my failure, but can access my changes tomorrow morning earliest. @nmav Thanks, I will merge all needed changes from your code into this MR. Looks like we have all pieces of the puzzle now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138163236 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 21:21:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 20:21:38 +0000 Subject: [gnutls-devel] GnuTLS | Valid CA certificate rejected by GnuTLS (#693) In-Reply-To: References: Message-ID: Thanks for the report. Just build your example and... ``` $ GNUTLS_DEBUG_LEVEL=9 ./x gnutls[2]: Enabled GnuTLS 3.6.5 logging... gnutls[2]: getrandom random generator was detected gnutls[2]: Intel SSSE3 was detected gnutls[2]: Intel AES accelerator was detected gnutls[2]: Intel GCM accelerator (AVX) was detected gnutls[2]: unable to access: /etc/gnutls/default-priorities: 2 gnutls[2]: signatureAlgorithm.algorithm differs from tbsCertificate.signature.algorithm: 1.2.840.113549.1.1.5, 1.2.840.113549.1.1.12 gnutls[3]: ASSERT: x509.c[compare_sig_algorithm]:328 gnutls[3]: ASSERT: x509.c[gnutls_x509_crt_import]:562 gnutls[3]: ASSERT: x509.c[gnutls_x509_crt_list_import]:3797 gnutls[3]: ASSERT: verify-high2.c[gnutls_x509_trust_list_add_trust_mem]:92 GnuTLS processed -43 roots ``` Looks like GnuTLS is too pedantic for this cert: `signatureAlgorithm.algorithm differs from tbsCertificate.signature.algorithm`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/693#note_138165019 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 21:26:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 20:26:39 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Sure thing, thanks for looking into it! :dancers: :clap: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138165859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 21:36:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 20:36:07 +0000 Subject: [gnutls-devel] GnuTLS | Valid CA certificate rejected by GnuTLS (#693) In-Reply-To: References: Message-ID: I see, thanks! Is there any way to instruct GnuTLS to continue loading the PEM bundle and just skip over the ones it doesn't like? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/693#note_138167518 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 22:02:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 21:02:47 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: LGTM. Let's see how this will behave -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908#note_138174132 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 4 22:09:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 04 Feb 2019 21:09:06 +0000 Subject: [gnutls-devel] GnuTLS | Support PKCS 7 decryption (#152) In-Reply-To: References: Message-ID: Issue was reopened by Dmitry Eremin-Solenikov Issue 152: https://gitlab.com/gnutls/gnutls/issues/152 -- 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 Tue Feb 5 09:44:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 08:44:54 +0000 Subject: [gnutls-devel] GnuTLS | Valid CA certificate rejected by GnuTLS (#693) In-Reply-To: References: Message-ID: Doesn't look like that is currently possible (after a quick code scan). Feel free to open an issue for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/693#note_138277795 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 09:48:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 08:48:58 +0000 Subject: [gnutls-devel] GnuTLS | Use https:// instead of http:// in docs, README, examples, ... (#695) References: Message-ID: New Issue was created. Issue 695: https://gitlab.com/gnutls/gnutls/issues/695 Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/695 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 11:02:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 10:02:32 +0000 Subject: [gnutls-devel] GnuTLS | Use https:// instead of http:// in docs, README, examples, ... (#695) In-Reply-To: References: Message-ID: I've updated it make it more specific and added the backlog label. Please update if more are expected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/695#note_138301152 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 11:04:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 10:04:14 +0000 Subject: [gnutls-devel] GnuTLS | Valid CA certificate rejected by GnuTLS (#693) In-Reply-To: References: Message-ID: That's an interesting CA. One field of it claims RSA-SHA1 signature while the other RSA-SHA384. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/693#note_138301791 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 11:24:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 10:24:26 +0000 Subject: [gnutls-devel] GnuTLS | Use https:// instead of http:// in docs, README, examples, ... (#695) In-Reply-To: References: Message-ID: For most of the occurrences we can use a line of sed. Description added with how to create the TODO list. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/695#note_138312844 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 11:44:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 10:44:03 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) In-Reply-To: References: Message-ID: I'm trying to think if we can do this at all without breaking ABI expectations. Previously a client would set the PSK credentials (e.g., a callback), with `gnutls_psk_set_client_credentials_function(psk_cred, psk_callback)` and will be called only if `PSK` is listed as priority string, and PSK is negotiated (under TLS1.2), or during client hello sending (under TLS1.3). If we enable the PSK ciphersuites explicitly we can have an application getting to the callback when previously it wouldn't get there if the `PSK` were not listed as priority strings. `gnutls-cli` itself works that way, and if we enable PSK unconditionally it asks for username when connecting to any site. Breaking `gnutls-cli` is not a big deal (we can fix it), but I worry if there are applications which rely on that behavior too (i.e., the PSK credentials are set but do not indicate the intention to use PSK). I'm open to suggestions here. An approach may be to mark the application as a PSK application via a `gnutls_init` flag, but that would be yet another way to specify PSK. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/680#note_138319341 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 12:45:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 11:45:09 +0000 Subject: [gnutls-devel] GnuTLS | Continue loading after rejected certificates in PEM bundles (#696) References: Message-ID: New Issue was created. Issue 696: https://gitlab.com/gnutls/gnutls/issues/696 Author: Tavis Ormandy Assignee: ## Description of the feature: Currently `gnutls_certificate_set_x509_trust_file()` will stop if it finds any certificate it cannot load, see issue #693. It would be nice if there was a way to instruct GnuTLS to continue loading the rest of the bundle, rather than having users edit (possibly root owned) files. ## Applications that this feature may be relevant to: Client applications. ## Is this feature implemented in other libraries (and which) See #693. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/696 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 12:48:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 11:48:27 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Are you going to stick with ax_code_coverage.m4 serial 32 I wonder? There's still that tiny bug which is only fixed in serial 33: `-A][M_DISTCHECK_CONFIGURE_FLAGS = \$(A][M_DISTCHECK_CONFIGURE_FLAGS) --disable-code-coverage` `+A][M_DISTCHECK_CONFIGURE_FLAGS := \$(A][M_DISTCHECK_CONFIGURE_FLAGS) --disable-code-coverage` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138390314 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 12:56:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 11:56:33 +0000 Subject: [gnutls-devel] GnuTLS | ax_code_coverage.m4: updated to latest macro (!909) In-Reply-To: References: Message-ID: Merge Request !909 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/909 Branches: tmp-code-coverage-update to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 13:04:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 12:04:10 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: We stick with ax_code_coverage.m4 serial 25, which works even without autoconv-archive being installed. We try to avoid autoconf-archive being a hard dependency. This MR works here with the combinations of autoconf-archive (not-installed|2018|2019). @schmidthubert Maybe you can test in your environment ? @nmav I didn't apply any of your changes since I could successfully `make code-coverage-capture` in all above combinations. Though if still needed, you might create an amended MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138394842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 14:39:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 13:39:52 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Ah, OK, I understand! :+1: I did a cleanup and direct checkout of https://gitlab.com/gnutls/gnutls/merge_requests/905/diffs?commit_id=749df0a99813e85c943c167a2b8d7f5e6fe0705e and everything went well, no problems! :smiley: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138429018 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 14:55:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 13:55:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: @nmav Added a small test in `pkcs11/pkcs11-token-raw.c` to cover the 'buffer too small' case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_138436787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 15:24:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 14:24:14 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Added some more comments to `fuzz/README.md`. Quick answer: The script downloads the OSS-Fuzz corpora of a given fuzzer, adds the files to our existing files and 'merges' them. This 'merge' step throws out superfluous corpora (data files that don't add new covered code paths). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_138447198 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 15:25:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 14:25:18 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Perfect, thank you for testing :thumbsup: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138447658 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 15:48:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 14:48:40 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/common-cert-key-exchange.c: > fail("Could not set key/cert: %s\n", gnutls_strerror(ret)); > > gnutls_init(&server, GNUTLS_SERVER); > - gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, > - serverx509cred); > - > - > if (server_priority) > assert(gnutls_priority_set_direct(server, server_priority, NULL) >= 0); > else > assert(gnutls_priority_set_direct(server, client_prio, NULL) >= 0); > > + gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, Further down you check the return value. Why not here as well ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138456523 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 15:55:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 14:55:23 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/auth/cert.c: > * 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 (apr_cert_list_length == 0) { > + ret = _gnutls_buffer_append_prefix(data, 24, 0); This '24' is not understandable from the near context. Comment, or even better is a good-named #define. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138459461 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 15:58:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 14:58:48 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/auth.c: > } > } > > + /* sanity tests */ > + if (type == GNUTLS_CRD_CERTIFICATE) { > + gnutls_certificate_credentials_t c = cred; > + unsigned i; > + bool allow_tls13 = 0; > + unsigned key_usage; > + > + if (c != NULL && c->ncerts > 0) { `ncerts` is unsigned, so `> 0` is superfluous. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138460731 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 16:00:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 15:00:23 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Apart from those tiny things, LGTM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138461470 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 16:55:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 15:55:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli starttls connection to XMPP fails with 'error receiving Message-ID: New Issue was created. Issue 697: https://gitlab.com/gnutls/gnutls/issues/697 Author: Hanno B?ck Assignee: I get regular connection errors with GnuTLS and XMPP servers. Please note this is *not* the problem of xmpp client vs. server (there's another bug for this), but a separate problem. The bug happens irregularly, sometimes I get a failure and the next try it works on the same host, so there seems to be some nondeterminism involved, sometimes connections succeed. Failure example: $ gnutls-cli --starttls-proto=xmpp jabber.ccc.de:5222 Processed 132 CA certificate(s). Resolving 'jabber.ccc.de:5222'... Connecting to '146.255.57.229:5222'... error receiving From gnutls-devel at lists.gnutls.org Tue Feb 5 17:06:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 16:06:12 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) References: Message-ID: New Merge Request !910 https://gitlab.com/gnutls/gnutls/merge_requests/910 Project:Branches: rockdaboot/gnutls:tmp-use-https 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 Not changed everywhere, e.g. in tests/ such changes may break tests. Needs careful manual work. Also places like src/libopts/ have not been changed - that should be done upstream. ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 18:48:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 17:48:31 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Hmm (after returning home): the reason I asked about serial 32 was: that serial 32 was the version I found in the m4 directory? So now I ran everything manually and it happened again (serial 32) and it seems that aclocal is overwriting your version 25 file with the newer version 32 from the newer autoreconf? This is what it looks like at the end when running `bootstrap ./bootstrap --skip-po`: [... snip ...] ![g](/uploads/ab0ff1918857f616e2ded43948daf230/g.PNG) So I don't think that is OK? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138519546 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 19:05:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 18:05:02 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: That is exactly what it should do. These warnings indeed show that the new ax_code_coverage.m4 has been placed into m4 (and also is now part of `aclocal.m4`). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138523194 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 19:11:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 18:11:57 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: OK then, thank you! :+1: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_138525020 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 21:53:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 20:53:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli starttls connection to XMPP fails with 'error receiving References: Message-ID: Reproducible here with Debian's 3.6.6-2. In the timeout case, we receive 1 byte less than in the success case. That makes gnutls-cli calling another select() which times out. The error message is wrong in this case. It should be 'timeout...'. strace Failure: ``` socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET6, sin6_port=htons(5222), inet_pton(AF_INET6, "2a02:1b8:10:31::229", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Das Netzwerk ist nicht erreichbar) close(3) = 0 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 write(1, "Connecting to '146.255.57.229:52"..., 39Connecting to '146.255.57.229:5222'... ) = 39 connect(3, {sa_family=AF_INET, sin_port=htons(5222), sin_addr=inet_addr("146.255.57.229")}, 16) = 0 sendto(3, "\246\356\232\322\214\220\235\315\210\253\222"..., 359, 0, NULL, 0) = 359 ... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/697#note_138561854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 23:22:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 22:22:13 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) References: Message-ID: New Issue was created. Issue 698: https://gitlab.com/gnutls/gnutls/issues/698 Author: Tavis Ormandy Assignee: ## Description of problem: I think GnuTLS might not be conforming with [RFC5280 section 4.1.1.2](https://tools.ietf.org/html/rfc5280#section-4.1.1.2). > This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3). GnuTLS does not consider the parameters of the `signatureAlgorithm` to be part of the `AlgorithmIdentifier`, and therefore the outer `signatureAlgorithm` can be different from the `tbsCertificate` `signatureAlgorithm`. This behavior does not match the behaviour of OpenSSL and NSS who do consider the parameters part of the identifier. I think that this isn't a security vulnerability on it's own (although, I am not a cryptographer), because most (do any?) algorithms don't specify any parameters. However, you can modify and add new objects to signed certificates and they will still verify. That ***really*** feels like it might have significant consequences, even though I don't have the crypto skills to analyze it. ## Version of gnutls used: 3.6.6 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Built from source ## How reproducible: I modified [this certificate](https://crt.sh/?id=18) to change the outer `signatureAlgorithm` to have a 1 byte BIT STRING object (rather than the RFC-required NULL object). I could make the object larger because the signature starts with an empty byte I can truncate (maybe there are certificates with more room). Steps to Reproduce: * Download the attached pem certificate. * Observe that the file is different from the original. * Notice that gnutls still verifies the certificate. OpenSSL does not consider it valid. ## Actual results: ``` $ certtool --verify-allow-broken --verify --infile AlgorithmIdentifer.parameters.pem Loaded system trust (299 CAs available) Subject: CN=RapidSSL CA,O=GeoTrust\, Inc.,C=US Issuer: CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US Checked against: CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US Signature algorithm: RSA-SHA1 Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. ``` ## Expected results: ``` $ openssl verify AlgorithmIdentifer.parameters.pem C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA error 7 at 0 depth lookup: certificate signature failure error AlgorithmIdentifer.parameters.pem: verification failed ``` If you look at the diff between the two certificates, you can see the changes I made: ```diff --- /dev/fd/63 2019-02-05 14:13:31.409400948 -0800 +++ /dev/fd/62 2019-02-05 14:13:31.409400948 -0800 @@ -1,4 +1,4 @@ - 0:d=0 hl=4 l= 981 cons: SEQUENCE + 0:d=0 hl=4 l= 982 cons: SEQUENCE 4:d=1 hl=4 l= 701 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 @@ -62,7 +62,7 @@ 655:d=4 hl=2 l= 52 cons: SEQUENCE 657:d=5 hl=2 l= 8 prim: OBJECT :Authority Information Access 667:d=5 hl=2 l= 40 prim: OCTET STRING [HEX DUMP]:3026302406082B060105050730018618687474703A2F2F6F6373702E67656F74727573742E636F6D - 709:d=1 hl=2 l= 13 cons: SEQUENCE + 709:d=1 hl=2 l= 14 cons: SEQUENCE 711:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 722:d=2 hl=2 l= 0 prim: NULL - 724:d=1 hl=4 l= 257 prim: BIT STRING + 722:d=2 hl=2 l= 1 prim: OCTET STRING :A + 725:d=1 hl=4 l= 257 prim: BIT STRING ``` Notice I just added an OCTET STRING where the parameters are supposed to be (in fact, the RFC says it SHALL be NULL, so this is non-conforming) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 5 23:33:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 05 Feb 2019 22:33:22 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: I don't know why my attachments keep failing, here it is again. [AlgorithmIdentifer.parameters.pem](/uploads/2d6f579e2cf9659c58f38186e995a344/AlgorithmIdentifer.parameters.pem) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698#note_138577226 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 05:49:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 04:49:17 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > * 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 (apr_cert_list_length == 0) { > + ret = _gnutls_buffer_append_prefix(data, 24, 0); It is referring to the 3 bytes mentioned above. I've clarified it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138614022 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 05:51:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 04:51:41 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/common-cert-key-exchange.c: > fail("Could not set key/cert: %s\n", gnutls_strerror(ret)); > > gnutls_init(&server, GNUTLS_SERVER); > - gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, > - serverx509cred); > - > - > if (server_priority) > assert(gnutls_priority_set_direct(server, server_priority, NULL) >= 0); > else > assert(gnutls_priority_set_direct(server, client_prio, NULL) >= 0); > > + gnutls_credentials_set(server, GNUTLS_CRD_CERTIFICATE, Nice catch, I've added asserts all over this file. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138614307 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 05:52:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 04:52:35 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth.c: > } > } > > + /* sanity tests */ > + if (type == GNUTLS_CRD_CERTIFICATE) { > + gnutls_certificate_credentials_t c = cred; > + unsigned i; > + bool allow_tls13 = 0; > + unsigned key_usage; > + > + if (c != NULL && c->ncerts > 0) { Do you mean replacing it with `!= 0`? I find the `> 0` to convey the intention better rather than the `!=` when reading the code. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138614394 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 09:59:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 08:59:12 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/auth/cert.c: > * 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 (apr_cert_list_length == 0) { > + ret = _gnutls_buffer_append_prefix(data, 24, 0); Scanned the source... 24 is the number of bits taken from argument 4 (size) to be put into 'data' using the correct byte-order (endianess). We possible could split `_gnutls_buffer_append_prefix` into `_gnutls_buffer_append_prefix8, _gnutls_buffer_append_prefix16, _gnutls_buffer_append_prefix24, _gnutls_buffer_append_prefix32` to have static inline functions without error checking. That way the code would also be much more readable, IMO. But this is not part of this issue ;-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138658627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 10:06:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 09:06:17 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/auth.c: > } > } > > + /* sanity tests */ > + if (type == GNUTLS_CRD_CERTIFICATE) { > + gnutls_certificate_credentials_t c = cred; > + unsigned i; > + bool allow_tls13 = 0; > + unsigned key_usage; > + > + if (c != NULL && c->ncerts > 0) { Prepare to see warnings from static analyzers when you compare like `unsigned-var with > 0`. Since it might be a hint that the programmer didn't know / respect the unsignedness of the variable. My personal favorite is to leave away redundant information whenever they add no value to the reader. In this case i prefer `if (c !=NULL && c->ncerts)` or even better `if (c && c->ncerts)`. If it wasn't against the GnuTLS coding style. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138660982 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 11:27:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 10:27:44 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli starttls connection to XMPP fails with 'error receiving References: Message-ID: Reassigned Issue 697 https://gitlab.com/gnutls/gnutls/issues/697 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/697 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 11:34:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 10:34:46 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) References: Message-ID: New Merge Request !911 https://gitlab.com/gnutls/gnutls/merge_requests/911 Branches: tmp-fix-cli-starttls-xmpp 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 two issues with gnutls-cli --starttls-proto=xmpp: 1. Print 'Timeout' on timeout instead of random errno message 2. Do not wait for linefeed when using XMPP (XML) Closes #697 ## 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/911 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 11:35:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 10:35:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli starttls connection to XMPP fails with 'error receiving References: Message-ID: !911 fixes this issue. Thanks for reporting. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/697#note_138690449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 11:42:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 10:42:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli starttls connection to XMPP fails with 'error receiving References: Message-ID: Short explanation: --starttls-proto works line(feed) oriented when waiting for expected input. But XMPP is XML and thus we can't rely on the server sending linefeed at all. The reason why it sometimes failed is message fragmentation / merging (in kernel or network layer). The first reply sometimes comes in as two packets - in this case we see a failure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/697#note_138692606 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 12:53:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 11:53:01 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth.c: > } > } > > + /* sanity tests */ > + if (type == GNUTLS_CRD_CERTIFICATE) { > + gnutls_certificate_credentials_t c = cred; > + unsigned i; > + bool allow_tls13 = 0; > + unsigned key_usage; > + > + if (c != NULL && c->ncerts > 0) { Updated -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902#note_138715273 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 12:53:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 11:53:18 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: All discussions on Merge Request !902 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/902 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 12:59:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 11:59:07 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: I've added few more tests in https://github.com/tomato42/tlsfuzzer/pull/506 that uncovered two more issues: 9. server does not detect when the `record_size_limit` extension is added or removed in 2nd CH in HRR handshake 10. server does respect `max_fragment_length` extension when both it and `record_size_limit` extension is sent -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_138717255 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 14:25:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 13:25:28 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Merge Request !902 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/902 Branches: tmp-key-usage to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 20:41:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 19:41:24 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_ntop() from gnulib (!912) References: Message-ID: New Merge Request !912 https://gitlab.com/gnutls/gnutls/merge_requests/912 Branches: tmp-gnulib-ntop 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 Use inet_ntop() from gnulib and remove code from lib/system/. ## 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/912 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 21:11:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 20:11:26 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) References: Message-ID: New Merge Request !913 https://gitlab.com/gnutls/gnutls/merge_requests/913 Branches: tmp-gnulib-pton 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 Removes code in lib/system and uses gnulib. ## 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/913 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 6 21:17:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 06 Feb 2019 20:17:25 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!914) References: Message-ID: New Merge Request !914 https://gitlab.com/gnutls/gnutls/merge_requests/914 Project:Branches: DK_DARKmatter/gnutls:master to gnutls/gnutls:master Author: Ke Zhao Assignee: The printf() function will generate output to the standard output stream. This causes applications which want to parse data from the TLS stream to filter out the logging messages. Instead, we use standard output so that applications don't have to parse this data. The result is that stdin and stdout are uniquely dedicated to stream data while stderr is used for logging messages. ## 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/914 You're receiving 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 Feb 7 11:47:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 07 Feb 2019 10:47:02 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: This MR needs to be rebased on !912, else the MinGW build fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913#note_139101806 You're receiving 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 Feb 7 15:57:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 07 Feb 2019 14:57:25 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/max_record.c: > } else { /* server side */ > > + if (session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_SENT) > + return 0; > + > if (session->security_parameters.max_record_recv_size != > DEFAULT_MAX_RECORD_SIZE) { > ret = _gnutls_mre_record2num > (session->security_parameters. > max_record_recv_size); > - > - /* it's not an error, as long as we send the > - * record_size_limit extension with that value */ > if (ret < 0) > - return 0; > + return gnutls_assert_val(ret); There _was_ [a test](https://gitlab.com/gnutls/gnutls/blob/master/tests/tls-record-size-limit.c#L319) but it didn't fail due to [a mishandling](https://gitlab.com/gnutls/gnutls/blob/master/lib/hello_ext.h#L162) of "max_fragment_length" sent by the client, where `id == 0`. I'm fixing this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139212580 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 11:53:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 10:53:03 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) References: Message-ID: New Merge Request !915 https://gitlab.com/gnutls/gnutls/merge_requests/915 Project:Branches: ansasaki/gnutls:fips140_ecdsa_kat to gnutls/gnutls:gnutls_3_3_x Author: Anderson Sasaki Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. When in FIPS mode, it is necessary to run an ECDSA known answer test at start-up for at least one approved curve to be able to use ECDSA and be compliant with FIPS requirements. ## 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/915 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 12:50:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 11:50:22 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: [Forget about POSIX, amended the isue description] While `size_t` is C standard, `ssize_t` is not. If it is not available, we should *not* typedef it to an `int`. E.g. on Win64, `int` is 32 bits and `size_t` is 64bits. IMO, we better leave it to the application programmer, to do the right thing. E.g. on Windows this could be ``` #include typedef SSIZE_T ssize_t; ``` before including `gnutls.h`. At the same time, we need a `ssize_t` when building GnuTLS. We can achieve that with `AC_TYPE_SSIZE_T` in `configure.ac`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139527392 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 13:04:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 12:04:40 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) References: Message-ID: New Merge Request !916 https://gitlab.com/gnutls/gnutls/merge_requests/916 Branches: tmp-ssize-t 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 Closes #688 ## 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/916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 13:05:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 12:05:00 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: Reassigned Issue 688 https://gitlab.com/gnutls/gnutls/issues/688 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 13:09:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 12:09:40 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_ntop() from gnulib (!912) In-Reply-To: References: Message-ID: Merge Request !912 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/912 Branches: tmp-gnulib-ntop to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/912 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 13:10:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 12:10:51 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_ntop() from gnulib (!912) 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/912#note_139533135 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 14:04:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 13:04:48 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_ntop() from gnulib (!912) In-Reply-To: References: Message-ID: Merge Request !912 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/912 Branches: tmp-gnulib-ntop to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/912 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 14:05:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 13:05:07 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_ntop() from gnulib (!912) 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/912#note_139548352 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 15:11:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 14:11:41 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: Merge Request !913 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/913 Branches: tmp-gnulib-pton to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 15:12:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 14:12:12 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: This too looks fine. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913#note_139588356 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:05:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:05:07 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < MIN_RECORD_SIZE) > return 0; > > - session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > + /* if a record size larger than user specified maximum, ignore it */ > + if (new_size > session->security_parameters.max_record_send_size) > + return 0; True, it is reverted in the later commit: 39058a8f3318fc9de4cc56f0ec900e223eea3725 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139604937 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:06:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:06:57 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < MIN_RECORD_SIZE) > return 0; > > - session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > + /* if a record size larger than user specified maximum, ignore it */ > + if (new_size > session->security_parameters.max_record_send_size) > + return 0; > > - /* if a larger record size limit than the protocol limit is > - * provided by the peer, ignore it and stick to the default */ > - if (unlikely(new_size > DEFAULT_MAX_RECORD_SIZE)) > - return gnutls_assert_val(0); > + session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > > - session->security_parameters.max_record_send_size = new_size; This should also be covered by 39058a8f3318fc9de4cc56f0ec900e223eea3725 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139605531 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:09:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:09:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/gnutls_int.h: > { > size_t max; > > - if (IS_DTLS(session)) { > - max = MIN(gnutls_dtls_get_data_mtu(session), session->security_parameters.max_record_send_size); > - } else { > - max = session->security_parameters.max_record_send_size; > - } > + max = MIN(session->security_parameters.max_record_send_size, > + session->security_parameters.max_record_recv_size); `max_record_recv_size` is documented as: ``` /* The send size is the one requested by the programmer. * The recv size is the one negotiated with the peer. */ uint16_t max_record_send_size; uint16_t max_record_recv_size; ``` That means both `max_record_send_size` and `max_record_recv_size` should be used for calculating the maximum user data (i.e. plaintext without content type) to be sent. I will add doc string there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139606408 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:10:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:10:08 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/gnutls_int.h: > { > size_t max; > > - if (IS_DTLS(session)) { > - max = MIN(gnutls_dtls_get_data_mtu(session), session->security_parameters.max_record_send_size); > - } else { > - max = session->security_parameters.max_record_send_size; > - } > + max = MIN(session->security_parameters.max_record_send_size, > + session->security_parameters.max_record_recv_size); See the other comment. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139606508 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:12:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:12:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < MIN_RECORD_SIZE) > return 0; > > - session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > + /* if a record size larger than user specified maximum, ignore it */ > + if (new_size > session->security_parameters.max_record_send_size) > + return 0; > > - /* if a larger record size limit than the protocol limit is > - * provided by the peer, ignore it and stick to the default */ > - if (unlikely(new_size > DEFAULT_MAX_RECORD_SIZE)) > - return gnutls_assert_val(0); Yes, in https://gitlab.com/gnutls/gnutls/merge_requests/879/diffs?commit_id=39058a8f3318fc9de4cc56f0ec900e223eea3725#eed9c09cadb2e1fc877ebb77b9165ec9f0c432ce_76_81 it is actually clamped to `max_record_send_size`, whose default is `DEFAULT_MAX_RECORD_SIZE`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139607101 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:14:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:14:26 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > + /* we do not want to accept sizes outside of our supported range */ > + if (new_size < MIN_RECORD_SIZE) { > + /* for server, reject it by omitting the extension in the reply */ > + if (session->security_parameters.entity == GNUTLS_SERVER) > + return gnutls_assert_val(0); > + else > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + } > > session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > > - session->security_parameters.max_record_recv_size = new_size; > + _gnutls_handshake_log("EXT[%p]: record_size_limit %u negotiated\n", > + session, (unsigned)new_size); > + > + session->security_parameters.max_record_recv_size = The size is checked against plaintext if I understand correctly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139607805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:15:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:15:37 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < 64) > return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > > + /* the same size should be requested upon HRR */ > + if (unlikely > + (session->internals.hsk_flags & HSK_HRR_SENT && > + session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_RECEIVED && > + new_size != session->internals.peer_record_size_limit)) > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); I am going to defer this, until we decide how to handle #617. I excluded HRR probes in gnutls-nocert-tls13.json for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139609742 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:53:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:53:12 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > if (new_size < MIN_RECORD_SIZE) > return 0; > > - session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_NEGOTIATED; > + /* if a record size larger than user specified maximum, ignore it */ > + if (new_size > session->security_parameters.max_record_send_size) > + return 0; I partially squashed those commits. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139624087 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:53:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:53:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: All discussions on Merge Request !879 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/879 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 16:53:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 15:53:43 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > > - /* we do not want to accept sizes less than our minimum */ > - if (new_size < MIN_RECORD_SIZE) > - return 0; > + session->internals.hsk_flags |= HSK_RECORD_SIZE_LIMIT_RECEIVED; > > - /* if a record size larger than user specified maximum, ignore it */ > - if (new_size > session->security_parameters.max_record_send_size) > - return 0; > + /* we do not want to accept sizes outside of our supported range */ > + if (new_size < MIN_RECORD_SIZE) { > + /* for server, reject it by omitting the extension in the reply */ > + if (session->security_parameters.entity == GNUTLS_SERVER) > + return gnutls_assert_val(0); > + else > + return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); That's a good point; added log calls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_139624255 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 18:40:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 17:40:20 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: One thing to pay attention with such a change is the note in CONTRIBUTION.md about preventing the gnulib networking modules to enter the library. I do not remember if these particular functions bring it, but it may be given that we had worked-around them in the past. Bringing the gnulib networking modules in the library make it non-functional for windows applications that don't use gnulib. I do not know if that's the case with this change, but it would be safer to have a check that verifies that in windows the `recv()` and `send()` are the native windows calls and not the gnulib replacements before merging it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913#note_139651792 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 18:42:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 17:42:12 +0000 Subject: [gnutls-devel] GnuTLS | When negotiating TLS1.3 enforce certificate key usage (!902) In-Reply-To: References: Message-ID: Merge Request !902 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/902 Branches: tmp-key-usage to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/902 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 18:42:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 17:42:12 +0000 Subject: [gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #690: https://gitlab.com/gnutls/gnutls/issues/690 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 18:46:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 17:46:38 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/pkcs11/pkcs11-token-raw.c: > exit(1); > } > > + { /* Testing a too small buffer */ > + char buf[1]; > + size_t size = sizeof(buf); > + > + ret = gnutls_pkcs11_token_get_info("pkcs11:", This is a good start and it tests that a small value will return this error. It would be good to add: - success case; verify string is the expected - failure case; size is enough for string but not for null terminator to cover the main options in the code above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_139653012 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 22:02:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 21:02:21 +0000 Subject: [gnutls-devel] GnuTLS | WIP: support non-NULL-terminated PSKs (!917) References: Message-ID: New Merge Request !917 https://gitlab.com/gnutls/gnutls/merge_requests/917 Branches: ajuaristi-issue-586 to master Author: Ander Juaristi Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list I have not been able to test it. Compilation consistently fails to me (Ubuntu 18) since mid-January (see first commit date) and I can't tell why. I guess it's related to !662 but haven't gone further. I am researching it. Any clues? ../lib/.libs/libgnutls.so: undefined reference to `nettle_rsa_sec_decrypt at HOGWEED_4' Anyway, for now have a look to the new public functions I introduce and tell me if they seem good to you. This is a bit quirky because you need to introduce duplicates for everything (`gnutls_psk_set_client_credentials2`, `gnutls_psk_set_server_credentials2`, etc.). If you have a better idea I'm all ears. Add a description of the new feature/bug fix. Reference any relevant bugs. ## 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/917 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 22:04:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 21:04:56 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) In-Reply-To: References: Message-ID: See !917. I started working on that on mid-January (see first commit), but it consistently fails to compile since then and I still don't know why. I believe it's related to !662, but don't know for sure. I want to close this as soon as possible but this compile error has me stuck. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586#note_139691882 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 22:06:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 21:06:50 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) In-Reply-To: References: Message-ID: I've started working on this (see branch ajuaristi-issue-386) but first I want to close !917 and I'm currently having trouble. Just informing you ;) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/386#note_139692156 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 22:13:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 21:13:09 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: inet_pton / inet_ntop / inet_aton / inet_ntoa are just string->struct resp. struct->string functions and do not pull in I/O functions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913#note_139693049 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 8 22:46:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 08 Feb 2019 21:46:06 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) In-Reply-To: References: Message-ID: @juaristi Did you check that there is no old nettle version in /usr/local ? Is the system nettle recent enough ? If not, build the latest version and install it to /usr/local (don't forget `ldconfig` afterwards). The current compile error I see is ``` psk_passwd.c:138:1: error: conflicting types for '_gnutls_psk_pwd_find_entry' _gnutls_psk_pwd_find_entry(gnutls_session_t session, ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from psk_passwd.c:29: ./../auth/psk_passwd.h:24:5: note: previous declaration of '_gnutls_psk_pwd_find_entry' was here int _gnutls_psk_pwd_find_entry(gnutls_session_t, char *username, ^~~~~~~~~~~~~~~~~~~~~~~~~~ ``` Which clearly looks like WIP. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586#note_139697401 You're receiving 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 Feb 9 10:33:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 09:33:33 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) References: Message-ID: New Merge Request !918 https://gitlab.com/gnutls/gnutls/merge_requests/918 Branches: tmp-downgrade-sentinel 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 #689. ## Checklist * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## 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/918 You're receiving 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 Feb 9 10:55:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 09:55:36 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap: refuse to bootstrap if any dependencies bring gnulib's network stack (!919) References: Message-ID: New Merge Request !919 https://gitlab.com/gnutls/gnutls/merge_requests/919 Branches: tmp-enforce-gnulib-rules-for-lib 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 If gnulib's network stack is brought (due to a dependency) in the library it will make the library unusable to non-gnulib using applications. This prevents windows applications for example to use gnutls, and so on. Even more it is quite hard to catch that issue because our testsuite uses gnulib as well. Instead we try to catch the these modules at import time ## 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/919 You're receiving 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 Feb 9 10:57:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 09:57:06 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap: refuse to bootstrap if any dependencies bring gnulib's network stack (!919) In-Reply-To: References: Message-ID: This was tested manually, by adding recvfrom in `gnulib_modules` and checking that the detection works. @rockdaboot what do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/919#note_139739518 You're receiving 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 Feb 9 17:30:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 16:30:27 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: I've opened !919 to enforce that these don't come indirectly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913#note_139816419 You're receiving 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 Feb 9 18:54:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 17:54:10 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) In-Reply-To: References: Message-ID: Moving to a 3.7.0 milestone which will gather all proposed behavioral changes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/680#note_139822244 You're receiving 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 Feb 9 18:54:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 17:54:13 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.7.0 ( https://gitlab.com/gnutls/gnutls/milestones/20 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/680 You're receiving 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 Feb 9 18:56:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 17:56:40 +0000 Subject: [gnutls-devel] GnuTLS | Replace AUTHORS with CODEOWNERS (#606) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #606: https://gitlab.com/gnutls/gnutls/issues/606 -- 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 Feb 9 18:56:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 17:56:39 +0000 Subject: [gnutls-devel] GnuTLS | Replace AUTHORS with CODEOWNERS (#606) In-Reply-To: References: Message-ID: This was discussed and was found unnecessary. The current authors form seems sufficient. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/606#note_139822410 You're receiving 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 Feb 9 18:58:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 17:58:08 +0000 Subject: [gnutls-devel] GnuTLS | do not tolerate DER encoded certificates with invalid time format (#207) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.7.0 ( https://gitlab.com/gnutls/gnutls/milestones/20 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/207 You're receiving 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 Feb 9 19:00:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:00:20 +0000 Subject: [gnutls-devel] GnuTLS | cryptopro TLS extension is defined as a server-only extension (#304) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #304: https://gitlab.com/gnutls/gnutls/issues/304 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/304 You're receiving 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 Feb 9 19:00:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:00:45 +0000 Subject: [gnutls-devel] GnuTLS | cryptopro TLS extension is defined as a server-only extension (#304) In-Reply-To: References: Message-ID: This is not an extension we currently support. Closing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/304#note_139822681 You're receiving 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 Feb 9 19:01:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:01:12 +0000 Subject: [gnutls-devel] GnuTLS | handle OID 1.3.6.1.4.1.11129.2.4.2 (x.509 extension for certificate transparency SCTs) (#232) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/232 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Feb 9 19:01:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:01:54 +0000 Subject: [gnutls-devel] GnuTLS | change or make configurable to number of tickets to send by default (#596) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/596 You're receiving 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 Feb 9 19:02:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:02:25 +0000 Subject: [gnutls-devel] GnuTLS | change or make configurable to number of tickets to send by default (#596) In-Reply-To: References: Message-ID: We should send at least 2 tickets by default to make session resumption by clients that open more than a single connection more efficient. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/596#note_139822789 You're receiving 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 Feb 9 19:06:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:06:25 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: @dueno are you ok with this policy? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908#note_139823052 You're receiving 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 Feb 9 19:06:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:06:35 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap: refuse to bootstrap if any new dependencies bring gnulib's network stack (!919) In-Reply-To: References: Message-ID: LGTM, good idea ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/919#note_139823059 You're receiving 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 Feb 9 19:06:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:06:38 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap: refuse to bootstrap if any new dependencies bring gnulib's network stack (!919) In-Reply-To: References: Message-ID: Merge Request !919 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/919 Branches: tmp-enforce-gnulib-rules-for-lib to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/919 You're receiving 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 Feb 9 19:06:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:06:43 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap: refuse to bootstrap if any new dependencies bring gnulib's network stack (!919) In-Reply-To: References: Message-ID: Merge Request !919 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/919 Branches: tmp-enforce-gnulib-rules-for-lib to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/919 You're receiving 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 Feb 9 19:23:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 18:23:50 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: windows has both size_t and ssize_t according to [this page](https://docs.microsoft.com/en-us/windows/desktop/winprog/windows-data-types), so I doubt this is affecting any platforms we care. However, any platform affected will break compilation, and with a fix like the above, the ABI as well. What about we move that change to a more prominent release? I made the 3.7.0 milestone for similar changes. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139824331 You're receiving 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 Feb 9 20:16:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 19:16:46 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: I don't mind 'milestoning' it to 3.7.0. But - your page just claims that `SSIZE_T` is available on Windows, not `ssize_t`. That conforms to my previous comment (and all the references/discussion that I found). - why should compilation fail ? `AC_TYPE_SSIZE_T` always gives us a `ssize_t`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139827444 You're receiving 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 Feb 9 21:20:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 20:20:55 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: I assumed (apparently wrongly) that capitals was irrelevant there. About the compilation I was referring to application compilation not gnutls' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139831627 You're receiving 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 Feb 9 23:46:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 09 Feb 2019 22:46:07 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: > About the compilation I was referring to application compilation not gnutls' Yeah, that's the point. We should think about that and either avoid ssize_t or explicitly check for Windows and do the right thing (see above). But the current `typedef int ssize_t` seems to be wrong on 64bit systems. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139840628 You're receiving 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 Feb 10 05:29:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 04:29:45 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: Sure, looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908#note_139852835 You're receiving 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 Feb 10 08:25:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 07:25:35 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: Merge Request !908 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/908 Branches: tmp-gitlab-triage to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908 You're receiving 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 Feb 10 08:26:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 07:26:02 +0000 Subject: [gnutls-devel] GnuTLS | .triage-policies.yml: added [ci skip] (!908) In-Reply-To: References: Message-ID: Merge Request !908 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/908 Branches: tmp-gitlab-triage to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/908 You're receiving 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 Feb 10 08:27:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 07:27:37 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.7.0 ( https://gitlab.com/gnutls/gnutls/milestones/20 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688 You're receiving 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 Feb 10 10:23:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 09:23:08 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) References: Message-ID: New Merge Request !920 https://gitlab.com/gnutls/gnutls/merge_requests/920 Project:Branches: GostCrypt/gnutls:gost-cleaned-cnt 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 This adds support for CNT_IMIT ciphersuite from draft-smyshlyaev-tls12-gost-suites-04. It is using numbers assigned by IANA now, so it is not compatible with existing deployments till they are updated to use newly assigned numbers. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## 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/920 You're receiving 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 Feb 10 10:40:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 09:40:16 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: Merge Request !916 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/916 Branches: tmp-ssize-t to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916 You're receiving 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 Feb 10 10:40:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 09:40:23 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916#note_139864145 You're receiving 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 Feb 10 12:23:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 11:23:10 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: tlsfuzzer fails till [this PR](https://github.com/tomato42/tlsfuzzer/pull/513) is merged. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_139870622 You're receiving 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 Feb 10 14:15:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 13:15:49 +0000 Subject: [gnutls-devel] build-images | Debian-cross: Install datefudge from right architecture (!19) References: Message-ID: New Merge Request !19 https://gitlab.com/gnutls/build-images/merge_requests/19 Branches: tmp-datefudge-cross to master Author: Tim R?hsen Assignee: datefudge was installed in it's amd64 version, LD_PRELOAD wasn't working at all during 'make check'. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/19 You're receiving 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 Feb 10 14:29:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 13:29:05 +0000 Subject: [gnutls-devel] build-images | Debian-cross: Install datefudge from right architecture (!19) In-Reply-To: References: Message-ID: Merge Request !19 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/19 Branches: tmp-datefudge-cross 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/19 You're receiving 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 Feb 10 16:46:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 15:46:57 +0000 Subject: [gnutls-devel] GnuTLS | Use inet_pton() from gnulib (!913) In-Reply-To: References: Message-ID: Merge Request !913 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/913 Branches: tmp-gnulib-pton to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/913 You're receiving 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 Feb 10 18:21:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:21:26 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/pkcs11/pkcs11-token-raw.c: > exit(1); > } > > + { /* Testing a too small buffer */ > + char buf[1]; > + size_t size = sizeof(buf); > + > + ret = gnutls_pkcs11_token_get_info("pkcs11:", Both has been added -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_139897077 You're receiving 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 Feb 10 18:21:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:21:26 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: All discussions on Merge Request !906 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/906 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906 You're receiving 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 Feb 10 18:37:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:37:11 +0000 Subject: [gnutls-devel] GnuTLS | Bad assumption about sizeof long in src/serv-args.c (#700) References: Message-ID: New Issue was created. Issue 700: https://gitlab.com/gnutls/gnutls/issues/700 Author: Tim R?hsen Assignee: In our 32bit MinGW runner, `long` seems to be 32bit. And thus this code is wrong: ``` static void doOptMaxearlydata(tOptions* pOptions, tOptDesc* pOptDesc) { static struct {long rmin, rmax;} const rng[1] = { { 1, 4294967296 } }; ``` The value `4294967296` is `0` when put into a 32bit integer. Better to use `long long` or `uint64_t` or `4294967295`. I didn't have time to look further into the code, so I can't judge what option is appropriate. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/700 You're receiving 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 Feb 10 18:41:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:41:03 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: The mingw64 builds we are shipping are fine, so this doesn't seem to affect any platform. I think we should remove it even in 3.6.x as unused code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_139898703 You're receiving 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 Feb 10 18:43:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:43:06 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on configure.ac: > > AM_CONDITIONAL(NEED_LIBOPTS, test "$included_libopts" = "yes") > > -AC_CHECK_TYPE(ssize_t, > - [ > - DEFINE_SSIZE_T="#include " > - AC_SUBST(DEFINE_SSIZE_T) > - ], [ > - AC_DEFINE([NO_SSIZE_T], 1, [no ssize_t type was found]) > - DEFINE_SSIZE_T="typedef int ssize_t;" > - AC_SUBST(DEFINE_SSIZE_T) > - ], [ > - #include > - ]) > +# make sure we have a 'ssize_t' type > +AC_TYPE_SSIZE_T do we need this at all? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916#note_139898872 You're receiving 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 Feb 10 18:49:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:49:45 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: I think we are safe to assume `ssize_t` unconditionally during build because we already assume a functional sockets subsystem and `ssize_t` is used extensively in sockets. The concern of that code was mainly our gnutls.h header having the right includes. The current code is either too old or over-engineered; I'm for getting rid of it completely. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916#note_139899370 You're receiving 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 Feb 10 18:53:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 17:53:32 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688 You're receiving 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 Feb 10 19:50:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 18:50:57 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: > > AM_CONDITIONAL(NEED_LIBOPTS, test "$included_libopts" = "yes") > > -AC_CHECK_TYPE(ssize_t, > - [ > - DEFINE_SSIZE_T="#include " > - AC_SUBST(DEFINE_SSIZE_T) > - ], [ > - AC_DEFINE([NO_SSIZE_T], 1, [no ssize_t type was found]) > - DEFINE_SSIZE_T="typedef int ssize_t;" > - AC_SUBST(DEFINE_SSIZE_T) > - ], [ > - #include > - ]) > +# make sure we have a 'ssize_t' type > +AC_TYPE_SSIZE_T If we need it or not depends on the official list of supported (build) platforms. But it doesn't hurt to include it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916#note_139903597 You're receiving 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 Feb 10 19:50:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 18:50:57 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: All discussions on Merge Request !916 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/916 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916 You're receiving 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 Feb 10 19:53:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 18:53:38 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: > I'm for getting rid of it completely and not looking back with other ssize_t simulators. I'm not argueing against it. So I'll remove it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916#note_139903781 You're receiving 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 Feb 10 22:55:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 21:55:23 +0000 Subject: [gnutls-devel] GnuTLS | Latest Debian.cross builds fail due to datefudge being installed (#701) References: Message-ID: New Issue was created. Issue 701: https://gitlab.com/gnutls/gnutls/issues/701 Author: Tim R?hsen Assignee: On the Debian.cross CI image we only installed amd64 datefudge. Several tests on cross-runners check for a working datefudge and SKIP if it is not found. Today, I installed datefudge for mips, arm64 and aarch64. Now 4 tests fail due to datefudge being found. Maybe datefudge doesn't work as expected !? Couldn't check yet. >From server-multi-keys.sh.log: ``` Checking whether server can utilize multiple keys Echo Server listening on IPv4 0.0.0.0 port 25282...done Echo Server listening on IPv6 :: port 25282...done *** Fatal error: Error in the certificate. Error in handshake: A TLS fatal alert has been received. Processed 1 CA certificate(s). Resolving 'localhost:25282'... Connecting to '::1:25282'... - Successfully sent 0 certificate(s) to server. - Server has requested a certificate. - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - no subject,issuer `CN=GnuTLS Test CA', serial 0x59897b84004ff2ed, RSA-PSS key 2048 bits, signed using RSA-SHA256, activated `2017-08-08 08:51:16 UTC', expires `9999-12-31 23:59:59 UTC', pin-sha256="NN1idWI1043ahir5N4qSOKf/6IXzP/X1Kj4Ki5Z97xo=" Public Key ID: sha1:6a7ea695c72a532d59eb8c2f46fdf1c60e21db29 sha256:34dd62756235d38dda862af9378a9238a7ffe885f33ff5f52a3e0a8b967def1a Public Key PIN: pin-sha256:NN1idWI1043ahir5N4qSOKf/6IXzP/X1Kj4Ki5Z97xo= - Status: The certificate is NOT trusted. The certificate chain uses not yet valid certificate. *** PKI verification of server certificate failed... Failure: 1. handshake with RSA should have succeeded! Exiting via signal 15 .sh (exit status: 1) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/701 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 00:04:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 10 Feb 2019 23:04:26 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: The question regarding two last patches: should I include GOST groups into `GROUP-EC-ALL`? Or leave them in a separate `GROUP-GOST-ALL` setting? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_139935686 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 08:58:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 07:58:46 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:13:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:13:35 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: That's a nice catch. I do not think that currently this affects any of our algorithms (only RSA-PSS uses parameters, and RSA-PSS is restricted to SHA256 or better), but this issue could cause more serious issues in the future. I went through `compare_sig_algorithm` in `lib/x509/x509.c` and it seems there is already a check for the parameters, but a typo makes their checking a void operation. Fixing the typo and adding your reproducer should be sufficient to address the issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698#note_140005363 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:23:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:23:28 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) References: Message-ID: New Merge Request !921 https://gitlab.com/gnutls/gnutls/merge_requests/921 Branches: tmp-fix-cert-params-checks 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 Each certificate has two fields to set the signature algorithm and parameters used for the digital signature. One of the fields is authenticated and the other is not. It is required from RFC5280 to enforce the equality of these fields, but currently due to an issue we wouldn't enforce the equality of the parameters fields. This fix corrects the issue. Resolves: #698 ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## 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/921 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:23:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:23:39 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: Reassigned Issue 698 https://gitlab.com/gnutls/gnutls/issues/698 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:25:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:25:16 +0000 Subject: [gnutls-devel] GnuTLS | Bad assumption about sizeof long in src/serv-args.c (#700) In-Reply-To: References: Message-ID: Isn't this auto-generated code from autogen? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/700#note_140008942 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:28:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:28:22 +0000 Subject: [gnutls-devel] GnuTLS | Bad assumption about sizeof long in src/serv-args.c (#700) In-Reply-To: References: Message-ID: That's true. So we have to address that in src/serv-args.def. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/700#note_140009694 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:35:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:35:01 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!914) In-Reply-To: References: Message-ID: Reassigned Merge Request 914 https://gitlab.com/gnutls/gnutls/merge_requests/914 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/914 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 09:41:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 08:41:23 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!914) In-Reply-To: References: Message-ID: Hi, it seems the CI is failing at this change. An test was relying on the particular behavior (stderr/stdout) prior to the change. Note that tools like `gnutls-cli` and `certtool` when used for connections are hard to modify their behavior with respect to stderr and stdout because they are often wrapped by other tools which we have no control on. May I suggest using a piecemeal approach? That is, split the change on different commits depending on the tool modified. You can see the effect of your changes by running `make check` locally on your machine. That way we can figure which are the less risky changes and get them in, and separate the most risky ones for a more detailed discussion. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/914#note_140013345 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 10:40:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 09:40:04 +0000 Subject: [gnutls-devel] GnuTLS | Bad assumption about sizeof long in src/serv-args.c (#700) In-Reply-To: References: Message-ID: Reassigned Issue 700 https://gitlab.com/gnutls/gnutls/issues/700 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/700 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 10:46:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 09:46:10 +0000 Subject: [gnutls-devel] GnuTLS | Latest Debian.cross builds fail due to datefudge being installed (#701) In-Reply-To: References: Message-ID: Can't reproduce locally after building the docker image... rebuilding it at Gitlab.com again. Hopefully a temp. error in the 32bit datefudge packages. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/701#note_140035456 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 11:04:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 10:04:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) References: Message-ID: New Merge Request !922 https://gitlab.com/gnutls/gnutls/merge_requests/922 Branches: tmp-serv-args 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 Fixing this warning seen on 32bit architectures: serv-args.c: In function 'doOptMaxearlydata': serv-args.c:1431:14: warning: overflow in conversion from 'long long int' to 'long int' changes value from '4294967296' to '0' [-Woverflow] { 1, 4294967296 } }; ^~~~~~~~~~ Closes #700 ## 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/922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 12:37:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 11:37:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on src/serv-args.def: > flag = { > name = maxearlydata; > arg-type = number; > - arg-range = "1->4294967296"; > + arg-range = "1->4294967295"; Good catch. I think `1->16384` would be sufficient here, because there is a protocol limit of plaintext size (in TLS 1.3, it is 2^14, excluding content type). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922#note_140082683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 13:24:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 12:24:49 +0000 Subject: [gnutls-devel] GnuTLS | release automation (#702) References: Message-ID: New Issue was created. Issue 702: https://gitlab.com/gnutls/gnutls/issues/702 Author: Nikos Mavrogiannopoulos Assignee: [a recent gitlab release added support for automating releases](https://docs.gitlab.com/ee/user/project/releases/index.html) we should evaluate it, and see whether it makes sense and it can replace our current release process. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/702 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 14:56:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 13:56:43 +0000 Subject: [gnutls-devel] GnuTLS | Latest Debian.cross builds fail due to datefudge being installed (#701) In-Reply-To: References: Message-ID: After some test on Gitlab.com CI I am still puzzled. E.g. `gnutls-cli-self-signed.sh` fails. Datefudge works (tested with `datefudge 2018-1-1 dat -u +%s`). `datefudge 2018-1-1 ../src/gnutls-cli -p 25055 localhost` fails as expected - but the error message is different than what we expect: ``` Status: The certificate is NOT trusted. The certificate issuer is unknown. The certificate chain uses not yet valid certificate. ``` We expect ``` Status: The certificate is NOT trusted. The certificate issuer is unknown. ``` The certificates data is `activated `2017-12-30 06:25:48 UTC', expires `2019-12-20 06:25:51 UTC'`. What really puzzles me is that on a local docker image (built from the same Dockerfile), all tests succeed. Could it be a qemu issue on the docker host ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/701#note_140157009 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 16:25:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 15:25:50 +0000 Subject: [gnutls-devel] GnuTLS | Latest Debian.cross builds fail due to datefudge being installed (#701) In-Reply-To: References: Message-ID: I just downloaded the docker image from Gitlab.com and run all the step from our .gitlab-ci.yml. All tests still succeed. Looks like a docker host issue. I will revert to changes to the Dockerfile for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/701#note_140193208 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 16:27:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 15:27:04 +0000 Subject: [gnutls-devel] build-images | Revert "Debian-cross: Install datefudge from right architecture" (!20) References: Message-ID: New Merge Request !20 https://gitlab.com/gnutls/build-images/merge_requests/20 Branches: tmp-revert to master Author: Tim R?hsen Assignee: This reverts commit 45ed176b8626dbc3511182626919db1a743e4e7a. This breaks 3 32bit cross runners, likely a docker host issue since the issue is not locally reproducable. See https://gitlab.com/gnutls/gnutls/issues/701 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/20 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 16:42:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 15:42:23 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) In-Reply-To: References: Message-ID: Is this something we should address first in the master branch, or is it already addressed there? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/915#note_140199812 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 16:47:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 15:47:42 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) In-Reply-To: References: Message-ID: This is already addressed there in the same way, running the test for secp256r1. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/915#note_140201931 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 16:49:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 15:49:23 +0000 Subject: [gnutls-devel] build-images | Revert "Debian-cross: Install datefudge from right architecture" (!20) In-Reply-To: References: Message-ID: Merge Request !20 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/20 Branches: tmp-revert 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/20 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 11 17:32:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 11 Feb 2019 16:32:18 +0000 Subject: [gnutls-devel] GnuTLS | tests/seccomp.c missing test for HAVE_GETRANDOM (#703) References: Message-ID: New Issue was created. Issue 703: https://gitlab.com/gnutls/gnutls/issues/703 Author: Andy Bailey Assignee: ## Description of problem: tests/seccomp.c calls: ADD_SYSCALL(getrandom, 0); without testing for HAVE_GETRANDOM surrounding the call with #ifdef HAVE_GETRANDOM seems to do the trick. ## Version of gnutls used: 3.6.5 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) ## How reproducible: Steps to Reproduce: * on a machine with older libc6 (I have 2.19), lacking getrandom(), run configure * configure will detect absence of getrandom, config.h has HAVE_GETRANDOM unset * run make ## Actual results: undefined reference error ## Expected results: build and link -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/703 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 07:57:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 06:57:57 +0000 Subject: [gnutls-devel] GnuTLS | WIP: x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Marking as WIP, because I had to remove one test from `chainverify.c` and I'd like to check whether we'll need to re-introduce it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_140413046 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 07:59:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 06:59:56 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) In-Reply-To: References: Message-ID: Reassigned Issue 689 https://gitlab.com/gnutls/gnutls/issues/689 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 11:15:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 10:15:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: @dueno Thanks, amended to 16384 now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922#note_140472417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 11:40:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 10:40:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/pkcs11/pkcs11-token-raw.c: > exit(1); > } > > + { /* Testing a too small buffer */ > + char buf[1]; > + size_t size = sizeof(buf); > + > + ret = gnutls_pkcs11_token_get_info("pkcs11:", Sorry, forgot to add the changes to the commit... here we go. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140482139 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 11:56:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 10:56:57 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) In-Reply-To: References: Message-ID: Thank you @rockdaboot it works now. I had Nettle installed in a local folder under /home and pkg-config pointing to it (I have always done it like that), but looks like the `ldconfig` bit was relevant here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586#note_140488394 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 12:26:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 11:26:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on src/serv-args.def: > flag = { > name = maxearlydata; > arg-type = number; > - arg-range = "1->4294967296"; > + arg-range = "1->4294967295"; I'm sorry, please disregard the previous comment; I forgot about that the maxearlydata applies to the total size of the multiple application_data records. So 4294967295 should be better here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922#note_140499202 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 12:34:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 11:34:24 +0000 Subject: [gnutls-devel] GnuTLS | Remove typedef'ing ssize_t in gnutls.h (!916) In-Reply-To: References: Message-ID: Merge Request !916 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/916 Branches: tmp-ssize-t to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 12:34:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 11:34:24 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #688: https://gitlab.com/gnutls/gnutls/issues/688 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 13:57:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 12:57:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: @tomato42 could you review this again? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_140539392 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 15:43:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 14:43:06 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) References: Message-ID: New Merge Request !923 https://gitlab.com/gnutls/gnutls/merge_requests/923 Branches: tmp-reset-after-free 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 This method prevents direct use-after-free and double-free 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/923 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 15:47:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 14:47:48 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: @dueno Back to 4294967295 now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922#note_140586747 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 15:52:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 14:52:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: Merge Request !922 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/922 Branches: tmp-serv-args to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 15:59:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 14:59:27 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: All discussions on Merge Request !922 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/922 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 16:00:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 15:00:27 +0000 Subject: [gnutls-devel] GnuTLS | Latest Debian.cross builds fail due to datefudge being installed (#701) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #701: https://gitlab.com/gnutls/gnutls/issues/701 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/701 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 17:41:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 16:41:31 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!914) In-Reply-To: References: Message-ID: Merge Request !914 was closed by Ke Zhao Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/914 Project:Branches: (removed):master to gnutls/gnutls:master Author: Ke Zhao Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/914 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 17:53:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 16:53:03 +0000 Subject: [gnutls-devel] GnuTLS | Bad assumption about sizeof long in src/serv-args.c (#700) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #700: https://gitlab.com/gnutls/gnutls/issues/700 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/700 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 17:53:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 16:53:03 +0000 Subject: [gnutls-devel] GnuTLS | Fix 32bit overflow issue in src/serv-args.def (!922) In-Reply-To: References: Message-ID: Merge Request !922 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/922 Branches: tmp-serv-args to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 21:26:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 20:26:47 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/handshake.c: > > _gnutls_handshake_log("HSK[%p]: Selected version %s\n", session, session->security_parameters.pversion->name); > > + /* set downgrade sentinel if the server supports TLS 1.3 and This will not set the special value if the server resumes a TLS1.2 session with session IDs. I'm not sure that's necessarily bad as the RFC doesn't say anything about resumption. Another side-effect is `_gnutls_user_hello_func` can be simplified, and does no longer need to call `_gnutls_gen_server_random` if I read it correctly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_140686177 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 12 22:06:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 12 Feb 2019 21:06:03 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: I've regenerated another certificate chain which has correct format while being invalid in the same way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_140693574 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 08:48:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 07:48:57 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: I am not sure whether using different definition of `gnutls_free` when used in gnutls or when outside is going to be non-confusing. After all `gnutls_free` is supposed to be a pointer to a function. We'll need a descriptive section of the situation with memory functions in the contribution guide. Why not make a real macro out of it (e.g., `GNUTLS_FREE`) and replace `gnutls_free` use in gnutls? That we can also export if useful for applications as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_140838108 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 08:56:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 07:56:08 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/pkcs11/pkcs11-token-raw.c: > exit(1); > } > > + { /* Testing a too small buffer */ > + char buf[1]; > + size_t size = sizeof(buf); > + > + ret = gnutls_pkcs11_token_get_info("pkcs11:", Thank you. I've amended it with some additional checks (e.g., that the size is as expected an each call). Let me know if that's ok. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140839711 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 09:13:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 08:13:23 +0000 Subject: [gnutls-devel] GnuTLS | tests/seccomp.c missing test for HAVE_GETRANDOM (#703) In-Reply-To: References: Message-ID: Interesting. The getrandom used there is the SYS_getrandom for syscall interface. glibc providing getrandom function is orthogonal. Maybe using `#ifdef SYS_getrandom` would do the trick. Would you like to send a merge request for this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/703#note_140844343 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 09:24:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 08:24:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Sure, that's good. BTW if the 'url' is just "pkcs11:", the returned size is 32 (or 33 ? not 100% sure) but `buf` is empty. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140847155 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 09:24:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 08:24:37 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on tests/pkcs11/pkcs11-token-raw.c: > exit(1); > } > > + { /* Testing a too small buffer */ > + char buf[1]; > + size_t size = sizeof(buf); > + > + ret = gnutls_pkcs11_token_get_info("pkcs11:", Sure, that's good. BTW if the 'url' is just "pkcs11:", the returned size is 32 (or 33 ? not 100% sure) but buf is empty. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140847379 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 09:38:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 08:38:48 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Did you see that "gnutls_x509_crt_init: Fix dereference of NULL pointer" was a previously unrecognized NULL pointer dereference - but after setting the freed pointer to NULL, clang's scan-build detected it. But back to the topic, my premises were - just apply when building GnuTLS - make it transparent, so we devs don't have to carry another macro in mind - do not care what policies outside projects have that include `gnutls.h` - (some more technical stuff, not relevant here) So, the idea was to just use `gnutls_free` as we all are used to instead of adding a new macro. By doing so, we can't do anything wrong or forget a new macro when changing or writing new code. It appears easy and elegant. Even if someone adds an additional (and redundant) `p=NULL` after a `gnutls_free(p)`, compilers would optimize it out. Clang even tells you that a previously assigned value wasn't used. This is why I am against adding a new macro. And exporting such is not of great use to any project. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_140851875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 12:51:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 11:51:03 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: I'd like to find some time to go through it, but I have not yet managed. It seems that `draft-smyshlyaev-tls12-gost-suites-04` is a draft not in the final phase, and the meaning of these ciphersuites can still change. I am not sure whether this ciphersuite fits the stable branch yet. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_140924157 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 13:07:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 12:07:51 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: This is fine with me. I wanted to have a reviewable reference. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_140931027 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 14:00:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 13:00:59 +0000 Subject: [gnutls-devel] GnuTLS | Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Ok, let's mark it as WIP then to avoid accidental merging. I'll try to provide comments soon. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_140956121 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 14:02:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 13:02:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Sure. Anyway, this MR e.g. pointed that we should update supported groups in one of tlsfuzzer tests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_140956770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 14:11:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 13:11:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Oh, sorry for that. If you could merge the right behavior in your patch and remove mine I think that would be the easiest to get in. Otherwise, I'll try to check it tomorrow. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140960555 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 15:10:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 14:10:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Your code is good. I just wanted to mention that (odd ?) behavior. Not sure if that is wanted or a unwanted side effect and if it's worth testing for or not. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140983042 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 15:12:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 14:12:50 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: BTW, commit author and signed-off-by differs ;-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_140983827 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 16:07:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 15:07:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Hmm. I have to mark GOST groups as TLS1.2-only (till they are specified for use with TLS 1.3). @nmav does adding a `TLS 1.3 suitable` flag to `supported_groups` array and then checking version at `_gnutls_supported_groups_recv_params()` sound good to you? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_141006537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 16:34:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 15:34:30 +0000 Subject: [gnutls-devel] GnuTLS | cppcheck skips most files in lib/ (#705) References: Message-ID: New Issue was created. Issue 705: https://gitlab.com/gnutls/gnutls/issues/705 Author: Tim R?hsen Assignee: Adding `--enable=information` and gives the following warning for most of our files in `lib/`: ``` noValidConfiguration:lib/algorithms/cert_types.c:0,information,This file is not analyzed. Cppcheck failed to extract a valid configuration. Use -v for more details. ``` Adding -v prints a lot stuff, mainly saying that cppcheck has a problem with `gl/c-ctype.h`. ``` The tested configurations have these preprocessor errors:\012HAVE_CONFIG_H=1 : [gl/c-ctype.h:78] #error "Only ASCII and EBCDIC are supported" ``` Setting `# define C_CTYPE_ASCII 1` hard-coded in `gl/c-ctype.h` (removing the #if check) seems to work out. Though cppcheck is extremely slow... BTW, in `gitlab-ci.yml` the cppcheck option `-Ilib/include` should be `-Ilib/includes`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/705 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:07:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:07:13 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on tests/suite/tls-fuzzer/gnutls-nocert-tls13.json: > "server_port": @PORT@, > "tests" : [ > {"name" : "test-record-size-limit.py", > + "comment" : "changed extension after HRR is not supported #617", > "arguments" : ["-p", "@PORT@", "--reply-AD-size", "685", > - "--minimal-size", "512", "--expect-size", "16383", > + "--minimal-size", "512", > "check if server accepts maximum size in TLS 1.3", > "check if server accepts minimal size in TLS 1.3", > "check if server omits extension for unrecognized size 64 in TLS 1.3", > "check if server omits extension for unrecognized size 511 in TLS 1.3", > "check server sent size in TLS 1.3", > "HRR sanity", > - "modified extension in 2nd CH in HRR handshake", using `-e` for it would make the comment relevant without need to look at git history -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141035535 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:21:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:21:00 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: The tlsfuzzer submodule doesn't include the new tests added in PR#506, it should be updated to at least d388c6afa7b -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141040732 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:24:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:24:01 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup lib/auth/cert.c as suggested by cppcheck (!924) References: Message-ID: New Merge Request !924 https://gitlab.com/gnutls/gnutls/merge_requests/924 Branches: tmp-cleanup-cert 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 Clean up some code. ## 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/924 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:27:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:27:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: > The tlsfuzzer submodule doesn't include the new tests added in PR#506, it should be updated to at least d388c6afa7b I know. To enable those we need a fix for #689; otherwise, most of the TLS 1.3 tests fail. So I would stick to this version for now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141043162 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:34:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:34:16 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on lib/handshake.c: > > _gnutls_handshake_log("HSK[%p]: Selected version %s\n", session, session->security_parameters.pversion->name); > > + /* set downgrade sentinel if the server supports TLS 1.3 and to resume a TLS 1.2 session, you need to negotiate TLS 1.2 first, as you can't resume a TLS 1.2 session in TLS 1.3 - so I'd say that it should be included even during session resumption -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_141046074 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:35:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:35:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: then that feels to me like it is blocked by !918 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141046587 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:37:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:37:11 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: That wouldn't block this because those new tests are either covered by our own tests (about max_fragment_length) or postponed for now (about HRR). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141047175 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:38:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:38:25 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: that postponing includes both dropped and added extension? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141047592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 17:39:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 16:39:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Yes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141048011 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 19:51:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 18:51:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Aha. applying all the changes to the test but without any changes in `lib/`, it succeeds. Something must have changed in the rewrite. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_141090067 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 13 22:46:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 13 Feb 2019 21:46:12 +0000 Subject: [gnutls-devel] GnuTLS | Support Service Name expression for Subject Alt Name (#51) In-Reply-To: References: Message-ID: hm, i provided the information after it was tagged "needinfo", but i saw no followup after that. The information i pointed to to, though, was the use of SRV for the dns-over-tls lookup, which was deprecated before that profiles draft was published as [RFC 8310](https://tools.ietf.org/html/rfc8310), in part because there were no good implementers that handled SRVNames. So i don't have a concrete use case any more :( -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/51#note_141129419 You're receiving 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 Feb 14 09:28:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 08:28:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: What would be the behavior of this regarding TLS1.3? Currently what we have is: 1. in the priority string parsing we disable TLS1.3 if some non-TLS1.2 capable algorithms are seen 2. early in the session (e.g., when setting credentials) the flag `INT_FLAG_NO_TLS13` is set in the session to disable TLS1.3 Would these curves/ciphersuite rely on these? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_141230088 You're receiving 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 Feb 14 09:54:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 08:54:41 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/cert-tests/invalid-sig: > exit ${rc} > fi > > +#check whether different parameters in tbsCertificate than the outer signature is tolerated > +${VALGRIND} "${CERTTOOL}" -e --infile "${srcdir}/data/invalid-sig4.pem" The long option is better readable/understandable (--verify-chain). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_141238078 You're receiving 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 Feb 14 10:00:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 09:00:26 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: LGTM. Just a general remark: It would be nice to have the 'recipe' to create the test data (certs, keys etc). Best would be script with the certtool invocation including the .cfg file/data. Having this in a comment within the source code would be also be fine. That makes it much easier to re-generate the test data later, or to create a new test based on an existing one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_141239925 You're receiving 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 Feb 14 10:00:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 09:00:33 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Merge Request !921 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/921 Branches: tmp-fix-cert-params-checks to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921 You're receiving 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 Feb 14 10:20:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 09:20:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: ??? All succeeds except "commit-check", as I said. You have to synchronize your author and signed-off-by email. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906#note_141246865 You're receiving 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 Feb 14 10:30:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 09:30:44 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: All discussions on Merge Request !906 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/906 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906 You're receiving 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 Feb 14 11:22:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:22:39 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Unfortunately this certificate chain was generated using a lot of juggling. I've added a short description of it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_141270445 You're receiving 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 Feb 14 11:23:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:23:36 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/cert-tests/invalid-sig: > exit ${rc} > fi > > +#check whether different parameters in tbsCertificate than the outer signature is tolerated > +${VALGRIND} "${CERTTOOL}" -e --infile "${srcdir}/data/invalid-sig4.pem" I've used that instead -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921#note_141270787 You're receiving 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 Feb 14 11:23:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:23:36 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: All discussions on Merge Request !921 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/921 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921 You're receiving 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 Feb 14 11:25:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:25:33 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Merge Request !906 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/906 Branches: tmp-fix-uninitialized2 to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906 You're receiving 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 Feb 14 11:29:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:29:49 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) In-Reply-To: References: Message-ID: Merge Request !915 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/915 Project:Branches: ansasaki/gnutls:fips140_ecdsa_kat to gnutls/gnutls:gnutls_3_3_x Author: Anderson Sasaki Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/915 You're receiving 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 Feb 14 11:29:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:29:55 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/915#note_141273437 You're receiving 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 Feb 14 11:30:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 10:30:27 +0000 Subject: [gnutls-devel] GnuTLS | fips140: Run ECDSA self-test in startup for FIPS (!915) In-Reply-To: References: Message-ID: Merge Request !915 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/915 Project:Branches: ansasaki/gnutls:fips140_ecdsa_kat to gnutls/gnutls:gnutls_3_3_x Author: Anderson Sasaki Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/915 You're receiving 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 Feb 14 12:07:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 11:07:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!906) In-Reply-To: References: Message-ID: Merge Request !906 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/906 Branches: tmp-fix-uninitialized2 to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/906 You're receiving 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 Feb 14 12:57:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 11:57:24 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #698: https://gitlab.com/gnutls/gnutls/issues/698 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698 You're receiving 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 Feb 14 12:57:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 11:57:24 +0000 Subject: [gnutls-devel] GnuTLS | outer AlgorithmIdentifer parameters are not verified against tbsCertificate (#698) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #698: https://gitlab.com/gnutls/gnutls/issues/698 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/698 You're receiving 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 Feb 14 12:57:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 11:57:24 +0000 Subject: [gnutls-devel] GnuTLS | x509: corrected issue in the algorithm parameters comparison (!921) In-Reply-To: References: Message-ID: Merge Request !921 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/921 Branches: tmp-fix-cert-params-checks to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/921 You're receiving 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 Feb 14 13:16:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 12:16:36 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: do not override GNULIB_SRCDIR (!925) References: Message-ID: New Merge Request !925 https://gitlab.com/gnutls/gnutls/merge_requests/925 Branches: tmp-macosx-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 This fixes compilation on MacOSX CI. ## 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/925 You're receiving 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 Feb 14 13:16:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 12:16:44 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: do not override GNULIB_SRCDIR (!925) In-Reply-To: References: Message-ID: Fix running at: https://travis-ci.org/nmav/gnutls/builds/493203758 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/925#note_141309354 You're receiving 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 Feb 14 14:01:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 13:01:48 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: then only that one nit is left -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141325132 You're receiving 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 Feb 14 14:59:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 13:59:47 +0000 Subject: [gnutls-devel] GnuTLS | tests/seccomp.c missing test for HAVE_GETRANDOM (#703) In-Reply-To: References: Message-ID: would be happy to, setting up my account now. Thanks, Nikos! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/703#note_141350510 You're receiving 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 Feb 14 15:50:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 14:50:00 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) References: Message-ID: New Merge Request !926 https://gitlab.com/gnutls/gnutls/merge_requests/926 Project:Branches: bailey3/gnutls:gnutls-703 to gnutls/gnutls:master Author: Andy Bailey Assignee: This is a fix for #703 On linux systems without __NR_getrandom, the ADD_SYSCALL(getrandom, 0) in tests/seccomp.c will result in a link failure later, so test for SYS_getrandom first. This was the fix recommended by @nmav, thanks! ## Checklist * [x] Code modified for feature * [NA] Test suite updated with functionality tests * [NA] Test suite updated with negative tests * [NA] 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/926 You're receiving 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 Feb 14 15:55:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 14:55:35 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: do not override GNULIB_SRCDIR (!925) In-Reply-To: References: Message-ID: Merge Request !925 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/925 Branches: tmp-macosx-fix to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/925 You're receiving 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 Feb 14 15:55:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 14:55:58 +0000 Subject: [gnutls-devel] GnuTLS | bootstrap.conf: do not override GNULIB_SRCDIR (!925) In-Reply-To: References: Message-ID: Merge Request !925 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/925 Branches: tmp-macosx-fix to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/925 You're receiving 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 Feb 14 15:56:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 14:56:49 +0000 Subject: [gnutls-devel] GnuTLS | tests/seccomp.c missing test for HAVE_GETRANDOM (#703) In-Reply-To: References: Message-ID: ok- I've sent over a merge request, I _think_ I followed the instructions correctly, but apologies in advance if I've botched it :) Thanks again, @nmav! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/703#note_141376460 You're receiving 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 Feb 14 16:22:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 15:22:44 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on tests/seccomp.c: > > /* to read from /dev/urandom */ > ADD_SYSCALL(read, 0); > +#ifdef SYS_getrandom `SYS_getrandom` will only be defined if you include the right header file. It seems this has been solved in `lib/nettle/sysrng-linux.c`. Taking that code, the needed include stuff looks like ``` #if defined(__linux__) # include #endif ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141388773 You're receiving 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 Feb 14 16:31:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 15:31:34 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: Andy Bailey commented on a discussion on tests/seccomp.c: > > /* to read from /dev/urandom */ > ADD_SYSCALL(read, 0); > +#ifdef SYS_getrandom Thanks @rockdaboot, testing an updated version of the patch now! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141391986 You're receiving 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 Feb 14 16:45:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 15:45:25 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: @bailey3 After testing locally, you can amend your commit with `git commit --amend tests/seccomp.c` and update this MR with `git push --force-with-lease`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141397057 You're receiving 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 Feb 14 17:03:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 16:03:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: All discussions on Merge Request !879 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/879 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879 You're receiving 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 Feb 14 17:03:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 16:03:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/suite/tls-fuzzer/gnutls-nocert-tls13.json: > "server_port": @PORT@, > "tests" : [ > {"name" : "test-record-size-limit.py", > + "comment" : "changed extension after HRR is not supported #617", > "arguments" : ["-p", "@PORT@", "--reply-AD-size", "685", > - "--minimal-size", "512", "--expect-size", "16383", > + "--minimal-size", "512", > "check if server accepts maximum size in TLS 1.3", > "check if server accepts minimal size in TLS 1.3", > "check if server omits extension for unrecognized size 64 in TLS 1.3", > "check if server omits extension for unrecognized size 511 in TLS 1.3", > "check server sent size in TLS 1.3", > "HRR sanity", > - "modified extension in 2nd CH in HRR handshake", Adjusted to exclusively use `-e`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_141403848 You're receiving 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 Feb 14 17:25:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 16:25:03 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: @bailey3 Author and Signed-off-by must have matching email addresses (see `git log`), else our commit-check fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141412557 You're receiving 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 Feb 14 18:05:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 17:05:36 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/handshake.c: > > _gnutls_handshake_log("HSK[%p]: Selected version %s\n", session, session->security_parameters.pversion->name); > > + /* set downgrade sentinel if the server supports TLS 1.3 and @hkario, is there such test in tlsfuzzer already? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_141429388 You're receiving 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 Feb 14 18:06:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 17:06:19 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: you guys are the best, thanks @rockdaboot I've amended the commit, and have tested builds and make check with and without HAVE_LIBSECCOMP set, I _think_ all is well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141429575 You're receiving 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 Feb 14 19:04:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 18:04:58 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr Master (!927) References: Message-ID: New Merge Request !927 https://gitlab.com/gnutls/gnutls/merge_requests/927 Project:Branches: DK_DARKmatter/gnutls:master to gnutls/gnutls:master Author: Ke Zhao Assignee: The printf() function will generate output to the standard output stream. This causes applications which want to parse data from the TLS stream to filter out the logging messages. Instead, we use standard output so that applications don't have to parse this data. The result is that stdin and stdout are uniquely dedicated to stream data while stderr is used for logging messages. ## 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/927 You're receiving 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 Feb 14 19:12:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 18:12:22 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > extern _SYM_EXPORT gnutls_calloc_function gnutls_calloc; > extern _SYM_EXPORT gnutls_free_function gnutls_free; > > +#ifdef GNUTLS_INTERNAL_BUILD Given that this is only internal, shouldn't it be in the internal `gnutls_int.h`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141447446 You're receiving 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 Feb 14 19:13:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 18:13:53 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/x509/pkcs12_bag.c: > _gnutls_free_datum(&bag->element[i].data); `_gnutls_free_datum` itself sets the freed value to null -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141447738 You're receiving 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 Feb 14 19:17:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 18:17:09 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: > Did you see that "gnutls_x509_crt_init: Fix dereference of NULL pointer" was a previously unrecognized NULL pointer dereference - but after setting the freed pointer to NULL, clang's scan-build detected it. That's great. > But back to the topic, my premises were > - just apply when building GnuTLS > - make it transparent, so we devs don't have to carry another macro in mind > - do not care what about policies of outside projects which include `gnutls.h` > - (some more technical stuff, not relevant here) > So, the idea was to just use `gnutls_free` as we all are used to instead of adding a new macro. By doing > so, we can't do anything wrong or forget a new macro when changing or writing new code. It appears easy > and elegant. Even if someone adds an additional (and redundant) `p=NULL` after a `gnutls_free(p)`, > compilers would optimize it out. Clang even tells you that a previously assigned value wasn't used. > > This is why I am against adding a new macro. And exporting such is not of great use to any project. I'm fine with it. I think though we should dedicate few sentences in `CONTRIBUTION.md` about the memory functions and describe that `gnutls_free` is a macro when used inside the library. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141448342 You're receiving 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 Feb 14 19:29:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 18:29:44 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: We should also be able to turn this off in the valgrind and address sanitizer CI runs, so that any memory errors are not masked by it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141454245 You're receiving 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 Feb 14 20:30:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:30:26 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: Merge Request !926 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/926 Project:Branches: bailey3/gnutls:gnutls-703 to gnutls/gnutls:master Author: Andy Bailey Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926 You're receiving 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 Feb 14 20:31:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:31:09 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: All discussions on Merge Request !926 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/926 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926 You're receiving 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 Feb 14 20:31:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:31:15 +0000 Subject: [gnutls-devel] GnuTLS | tests/seccomp.c missing test for HAVE_GETRANDOM (#703) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #703: https://gitlab.com/gnutls/gnutls/issues/703 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/703 You're receiving 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 Feb 14 20:31:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:31:16 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: Merge Request !926 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/926 Project:Branches: bailey3/gnutls:gnutls-703 to gnutls/gnutls:master Author: Andy Bailey Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926 You're receiving 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 Feb 14 20:31:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:31:50 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: Thanks and congrats to your first MR on Gitlab :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141467269 You're receiving 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 Feb 14 20:37:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:37:28 +0000 Subject: [gnutls-devel] GnuTLS | tests: wrap ADD_SYSCALL for getrandom in test for SYS_getrandom (!926) In-Reply-To: References: Message-ID: hey thanks to you and @nmav as well! Sometimes I avoid submitting minor stuff upstream because it can be such an effort to learn the conventions; you guys make it easy! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/926#note_141469345 You're receiving 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 Feb 14 20:51:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 19:51:52 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: > We should also turn this off in the valgrind and address sanitizer CI runs, so that any memory errors are not masked by it. IMO, no memory errors would be masked by this MR. Free'd pointers are set to `NULL`, so that *any* dereference will be fetched by valgrind and by ASAN. Pointer arithmetic with a NULL pointer has even a much higher chance to be detected by valgrind and ASAN (e.g. when the result is used as array/memory index). But maybe you have something in mind that I don't think of !? Regarding `CONTRIBUTION.md` I'd suggest a new section/paragraph with a short introduction to the basic GnuTLS memory functions. Is that OK ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141478302 You're receiving 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 Feb 14 22:35:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 14 Feb 2019 21:35:44 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: I wouldn't disable TLS1.3 if these groups are enabled in priority string: - it would be quite easy to disable TLS1.3 by misconfiguring priority string - it might make a sensible configuration for a server to support TLS1.3 with ECDSA, while falling back to TLS1.2 if client requests GOST cipher suite. I'm actually more concerned about the other direction: if client specifies TLS 1.3 and one of these groups (together with other known ones) we should not fail negotiation (currently GnuTLS will return icorrect_parameter, because GOST groups are not supported in key_share extension). So my first target is to ignore these groups when TLS 1.3 is selected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_141500564 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 08:22:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 07:22:18 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: >> We should also turn this off in the valgrind and address sanitizer CI runs, so that any memory errors are not masked by it. > But maybe you have something in mind that I don't think of !? I was thinking masking a double free such as: ``` gnutls_free(ptr); /* do something */ gnutls_free(ptr); ``` But thinking it further, this is now a "logic" error with no repercussions whatsoever, and the fact that we eliminate explicit nullifications, makes such modification of the lib (without gnutls_free setting ptr to null) quite impossible to operate. So I no longer think this is a good idea. > Regarding `CONTRIBUTION.md` I'd suggest a new section/paragraph with a short introduction to the basic GnuTLS memory functions. Is that OK ? It makes sense to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141609187 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 11:57:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 10:57:04 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: Checking what caused the errors, I saw that libgmp.so.10.hmac is missing in Fedora which makes the integrity tests to fail. I opened this [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1677600) to track the issue in Fedora. For now, I can workaround this by manually creating the hmac files. What do you think about this approach? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_141677738 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 17:04:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 16:04:37 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) References: Message-ID: New Merge Request !928 https://gitlab.com/gnutls/gnutls/merge_requests/928 Project:Branches: bmwiedemann/gnutls:date to gnutls/gnutls:master Author: Bernhard M. Wiedemann Assignee: 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 * [ ] 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 Without this patch, building gnutls in the year 2034 produced such a diff in various binaries: ```diff /usr/bin/certtool differs in ELF section .rodata @@ -1150,7 +1150,7 @@ 2e790 00000000 00000000 00000000 00000000 ................ 2e7a0 63657274 746f6f6c 20332e36 2e360a43 certtool 3.6.6.C 2e7b0 6f707972 69676874 20284329 20323030 opyright (C) 200 - 2e7c0 302d3230 31392046 72656520 536f6674 0-2019 Free Soft + 2e7c0 302d3230 33342046 72656520 536f6674 0-2034 Free Soft 2e7d0 77617265 20466f75 6e646174 696f6e2c ware Foundation, 2e7e0 20616e64 206f7468 6572732c 20616c6c and others, all 2e7f0 20726967 68747320 72657365 72766564 rights reserved ``` See https://reproducible-builds.org/ for why this matters. Also claiming Copyright for future years seems wrong. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 19:04:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 18:04:55 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Merge Request !879 was approved by Hubert Kario Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/879 Branches: tmp-fix-record-size-limit-resumption to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 19:17:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 18:17:26 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on lib/handshake.c: > > _gnutls_handshake_log("HSK[%p]: Selected version %s\n", session, session->security_parameters.pversion->name); > > + /* set downgrade sentinel if the server supports TLS 1.3 and one that does a TLS 1.2 resumption and then verifies that the sentinel was set? no but it's very simple to do, it requires doing a regular resumption test and only providing one more option to `ExpectServerHello` the `server_max_protocol=` with `(3, 4)` as parameter: [test-downgrade-protection.py](https://github.com/tomato42/tlsfuzzer/blob/13479e5a44bc10e3577fc28b921c5b999a363ce9/scripts/test-downgrade-protection.py#L149-L178) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_141836000 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 20:21:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 19:21:09 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!927) In-Reply-To: References: Message-ID: @nmav Would upstream prefer an option that specifies which file to send the debug output to? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/927#note_141852070 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 20:29:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 19:29:06 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) In-Reply-To: References: Message-ID: Good point ! What about ``` YEAR=`date -u -r ChangeLog +%Y 2>/dev/null || date --date=@`git log -1 --format=%ct` +%Y` ``` That would take the date from ChangeLog in case of building from a tarball. Building in a git directory would give us the year of the last commit. If you agree, please amend your commit and use '-s' to add a Signed-Off-By. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928#note_141853359 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 15 21:51:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 15 Feb 2019 20:51:26 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: ok, added syntax-highlighting and 'heap memory usage' section. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141866085 You're receiving 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 Feb 16 14:33:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 13:33:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on src/socket.c: > tv.tv_usec = 0; > ret = select(socket->fd + 1, &read_fds, NULL, NULL, &tv); > - if (ret <= 0) > - ret = -1; > - else > + if (ret > 0) > ret = recv(socket->fd, pbuf, left, 0); > - if (ret == -1 || ret == 0) { > - int e = errno; > - fprintf(stderr, "error receiving %s: %s\n", txt, strerror(e)); > + if (ret == -1) { > + fprintf(stderr, "error receiving '%s': %s\n", txt, strerror(errno)); > + exit(2); > + } else if (ret == 0) { > + fprintf(stderr, "error receiving '%s': Timeout\n", txt); > exit(2); It looks ok to me, but I think it would be more re-assuring if we add a test for it a la starttls-pop3.sh. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_141948631 You're receiving 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 Feb 16 14:39:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 13:39:36 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on configure.ac: > fi > > AX_CODE_COVERAGE > +AM_CONDITIONAL(LEGACY_CODE_COVERAGE_RULES, test -n "$CODE_COVERAGE_RULES") Is ax_code_coverage important enough to justify compatibility code? Why not go to the latest version? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_141949057 You're receiving 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 Feb 16 14:46:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 13:46:55 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: An alternative could be using `rnd-check-rollback-val.c` to check for resumption too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_141949535 You're receiving 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 Feb 16 16:23:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 15:23:45 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on configure.ac: > fi > > AX_CODE_COVERAGE > +AM_CONDITIONAL(LEGACY_CODE_COVERAGE_RULES, test -n "$CODE_COVERAGE_RULES") See my statements above. Updating to the latest ax_code_coverage we would introduce autoconf-archive as hard dependency... but please read my prior comments. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_141958315 You're receiving 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 Feb 16 17:44:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 16:44:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: I fail to escape the XML string in a convenient way for the `chat` application. The man page is not very helpful. So, I leave it to you (or someone accustomed to `chat`) to add the test. The data is ``` TIMEOUT 3 out: in: out: in: ``` (`in and `out` to make clear what should be sent/received). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_141968075 You're receiving 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 Feb 16 21:23:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 20:23:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: BTW, `starttls-pop3.sh` starts `gnutls-serv` - what for ??? Removing it doesn't change a thing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_141981658 You're receiving 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 Feb 16 22:32:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 16 Feb 2019 21:32:06 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) In-Reply-To: References: Message-ID: I integrated the git part and gave it prevalence over ChangeLog. However the fallback is still required because not all date implementations support -d or -r It is also worth nothing that a "Copyright 2019" will remain correct even in future years. And since expiry is usually 70 years after death of author, it does not have to be updated that often. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928#note_141985598 You're receiving 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 Feb 17 11:17:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 10:17:48 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) In-Reply-To: References: Message-ID: > It is also worth nothing that a "Copyright 2019" will remain correct even in future years. IMO that is true as long as the effected source isn't changed. And the only place we use @YEAR@ as substitution variable is `src/args-std.def.in`. Whenever someone runs `./configure` or `./config.status`, this file is processed and the copyright year in `src/args-std.def` becomes updated. This also seems wrong to me. We should only update the year if the source code changes - a not 100% but much better approach would be to *only* take the year of the last git commit. We could generate that within bootstrap.conf which is not part of a tarball build. @nmav WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928#note_142050601 You're receiving 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 Feb 17 13:04:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 12:04:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: If you put these strings into single quotes, and backslash the "'", doesn't it work? I'm not sure what is in and out here, but the format of the string is 'SUBSTRING_EXPECTED' 'STRING_TO_SEND'. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_142056922 You're receiving 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 Feb 17 13:12:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 12:12:28 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on configure.ac: > fi > > AX_CODE_COVERAGE > +AM_CONDITIONAL(LEGACY_CODE_COVERAGE_RULES, test -n "$CODE_COVERAGE_RULES") Can't we just bring the dependencies it requires? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142057375 You're receiving 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 Feb 17 18:50:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 17:50:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: In:/out: just for clarity. in=expected, out=to_send. Single quotes and backslashing was my first try. There might be other characters in the XML that have to be escaped. Or maybe the XML strings are too long for chat. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_142088399 You're receiving 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 Feb 17 18:55:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 17:55:21 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: We could, but why ? You would pull in dependencies that bit rot if not regularly (+ manually) maintained. That's IMO a bad idea when this MR provides a working approach for all situations now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142088804 You're receiving 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 Feb 17 19:06:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 18:06:02 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: I'd also second a suggestion to bring in all dependendend .m4 files and possibly drop them later if they become unnecessary. It's a pity that autoconf-archive macros are not written in backwards-compatible way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142089679 You're receiving 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 Feb 17 19:11:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 18:11:19 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: > ... and possibly drop them later if they become unnecessary. What makes them become unnecessary ? autoconf-archive (>= 2019) going into the mainstream distros ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142090143 You're receiving 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 Feb 17 21:18:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 17 Feb 2019 20:18:48 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Anyways, if both of you are ok with adding all the needed m4 files into the GnuTLS git repo, I'll do that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142099150 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 09:46:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 08:46:21 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) References: Message-ID: New Merge Request !929 https://gitlab.com/gnutls/gnutls/merge_requests/929 Project:Branches: chouquette/gnutls:thread_local_msvc to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. ## 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/929 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 12:48:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 11:48:03 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: For the expected chat only needs a substring so not everything needs to be pasted there and for sending we could use `"` instead of `'` if xml allows it. There is a similar string in sieve starttls test. I can try to check the testing of it within the week. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_142265803 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 12:49:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 11:49:42 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: You seem to have forked an old version of master and the commit message misses the signoff-by. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142266244 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 12:50:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 11:50:20 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Have you seen the inline comments? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_142266403 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 12:53:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 11:53:12 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: > Anyways, if both of you are ok with adding all the needed m4 files into the GnuTLS git repo, I'll do that. My main concern is (was) with the multiple options where only one, the old version of the script, is tested in our CI. That's why my preference is towards a single option which is tested and used by our CI. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142267249 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:10:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:10:12 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: Merge Request !879 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/879 Branches: tmp-fix-record-size-limit-resumption to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:11:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:11:05 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: No all... seems that my email provider (GMX) doesn't give me all notifications from Gitlab. Also - reproducible - it takes 15-30 minutes before I receive those emails. It's definitely the provider, obvious when looking at the email sources / server timestamps. I'll check your comments then... sorry for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_142274972 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:18:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:18:18 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup lib/auth/cert.c as suggested by cppcheck (!924) In-Reply-To: References: Message-ID: Merge Request !924 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/924 Branches: tmp-cleanup-cert to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/924 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:18:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:18:53 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup lib/auth/cert.c as suggested by cppcheck (!924) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/924#note_142277399 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:46:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:46:06 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Oops, you are correct, I was over the 3.6.6 tag. Rebased over master, and added signed-off -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142286103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 13:54:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 12:54:20 +0000 Subject: [gnutls-devel] GnuTLS | Session resumption randomly fails (#706) References: Message-ID: New Issue was created. Issue 706: https://gitlab.com/gnutls/gnutls/issues/706 Author: Hubert Kario Assignee: ## Description of problem: When using gnutls client, it randomly fails to resume session against both NSS and OpenSSL servers. ## Version of gnutls used: gnutls-3.6.5-2.el8 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) RHEL ## How reproducible: Steps to Reproduce: * set up NSS or OpenSSL server with TLS 1.3 support * connect to them using `gnutls-cli --resume` * look for presence of both `Resume Handshake was completed` and `This is a resumed session` ## Actual results: the `This is a resumed session` is sometimes missing, in case of OpenSSL, it also notes that it's a `New, TLSv1.3` session ## Expected results: all connections should be able to resume -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/706 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 14:14:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 13:14:53 +0000 Subject: [gnutls-devel] GnuTLS | Session resumption randomly fails (#706) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/706 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 14:18:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 13:18:24 +0000 Subject: [gnutls-devel] GnuTLS | Session resumption randomly fails (#706) In-Reply-To: References: Message-ID: It seems that under TLS1.3 the "*** This is a resumed session" is consistently missing, but under both TLS1.2 and TLS1.3 "Resume Handshake was completed" is consistently sent. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/706#note_142298011 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 14:18:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 13:18:46 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: Sorry, I completely missed this (and have now fixed my settings/mail filters to avoid missing more highlights in the future) I'll try to reproduce the issue on my end and re-submit a new MR -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860#note_142298137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 14:28:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 13:28:52 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: @rockdaboot it seems that in that case `check_if_signed` misdetected the author. The variable `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` seems empty. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142301785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:27:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:27:32 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: @nmav I have no idea why/how this can happen, if it's a git or a Gitlab issue. Before we start a work-around like "OK if `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` is empty", can we figure out what is going on ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142324272 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:36:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:36:17 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: I doubt this is related here, but having an accent in my name already bite me in the past on some CI (that being said, I suppose that you'd have encountered the issue with a `?` in your name) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142327439 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:45:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:45:24 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: @rockdaboot it seems it is a generic issue. Checking your pipelines seems to have the same behavior: https://gitlab.com/rockdaboot/gnutls/-/jobs/161747598 It looks like the variable is not reliable on forks other than origin? Or it could be a regression from gitlab site; https://gitlab.com/gitlab-org/ci-cd/team-tasks/issues/7 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142330878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:53:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:53:37 +0000 Subject: [gnutls-devel] GnuTLS | check_if_signed: Get source branch if not set (!930) References: Message-ID: New Merge Request !930 https://gitlab.com/gnutls/gnutls/merge_requests/930 Project:Branches: rockdaboot/gnutls:tmp-get-source-branch 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 Work around CI_MERGE_REQUEST_SOURCE_BRANCH_NAME issue in Gitlab.com CI. See !929 ## 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/930 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:55:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:55:03 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: @nmav I can reproduce locally... this MR's branch is not based (only) on master, another yet unmerged branch has been merged here already (if I interpret `gitk --all` correctly). !930 should fix it. It determines the current branch name if CI_MERGE_REQUEST_SOURCE_BRANCH_NAME is empty. A quick tests reveals that it comes back with `HEAD` for this MR. Which is OK and it works. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142334505 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 15:56:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 14:56:41 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: @chouquette Yes, I should have encountered that issue with `?` :-) But that seems to be no problem for Gitlab. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142336340 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 17:25:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 16:25:13 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) References: Message-ID: New Merge Request !931 https://gitlab.com/gnutls/gnutls/merge_requests/931 Project:Branches: chouquette/gnutls:use_topendir to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: This is reintroducing the changes from !835 (and thus reverting those introducing in !860) The failure was due to an incorrect byte order in the path provided to _topendir. I'm not sure if the 3rd patch is correct, there might be a macro/constant that can be use to express that the `_gnutls_utf8_to_ucs2` caller wants native by order. Patch 2 & 3 might be better of squashed, but for the sake of reviewing, I think they're better of split for now. ## 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/931 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 17:47:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 16:47:05 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/handshake.c: > > _gnutls_handshake_log("HSK[%p]: Selected version %s\n", session, session->security_parameters.pversion->name); > > + /* set downgrade sentinel if the server supports TLS 1.3 and OK, so I ended up with regenerating server random upon handling "supported_versions" extension - that could effectively delay the setting of downgrade sentinel. Also modified `rnd-check-rollback-val.c` to cover the resumption case. Thank you for the suggestions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_142376123 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 17:47:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 16:47:07 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: All discussions on Merge Request !918 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/918 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 21:41:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 20:41:30 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) References: Message-ID: New Issue was created. Issue 707: https://gitlab.com/gnutls/gnutls/issues/707 Author: Fred Assignee: ## Description of problem: When using Knot Resolver (3.2.0-1 as included in Debian Buster) with TLS_FORWARD to 1.1.1.1 or 9.9.9.9, sometimes, seemingly random, an assert is hit and decryption fails. This is on an AMD Ryzen 5 1600 CPU. ``` Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Allocating epoch #0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) added 4 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list Feb 18 21:05:18 piranha kresd[6366]: [08443.17][wrkr] => connecting to: '9.9.9.9#00853' Feb 18 21:05:18 piranha kresd[6366]: [wrkr]=> connected to '9.9.9.9#00853' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Allocating epoch #1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: Adv. version: 3.3 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Maximum Record Size/1) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (OCSP Status Request/5) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension OCSP Status Request/5 (5 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Client Certificate Type/19) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Server Certificate Type/20) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Supported Groups/10) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group SECP256R1 (0x17) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group SECP384R1 (0x18) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group SECP521R1 (0x19) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group X25519 (0x1d) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group FFDHE2048 (0x100) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group FFDHE3072 (0x101) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group FFDHE4096 (0x102) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group FFDHE6144 (0x103) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sent group FFDHE8192 (0x104) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Supported Groups/10 (20 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Supported EC Point Formats/11) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Supported EC Point Formats/11 (2 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (SRP/12) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Signature Algorithms/13) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (4.1) RSA-SHA256 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.9) RSA-PSS-SHA256 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.4) RSA-PSS-RSAE-SHA256 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (4.3) ECDSA-SHA256 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.7) EdDSA-Ed25519 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (5.1) RSA-SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.10) RSA-PSS-SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.5) RSA-PSS-RSAE-SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (5.3) ECDSA-SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (6.1) RSA-SHA512 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.11) RSA-PSS-SHA512 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (8.6) RSA-PSS-RSAE-SHA512 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (6.3) ECDSA-SHA512 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (2.1) RSA-SHA1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sent signature algo (2.3) ECDSA-SHA1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Signature Algorithms/13 (32 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (SRTP/14) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Heartbeat/15) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (ALPN/16) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Encrypt-then-MAC/22) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Encrypt-then-MAC/22 (0 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Extended Master Secret/23) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Extended Master Secret/23 (0 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Session Ticket/35) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Session Ticket/35 (0 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Key Share/51) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sending key share for SECP256R1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: sending key share for X25519 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Key Share/51 (107 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Supported Versions/43) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Advertizing version 3.4 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) Advertizing version 3.3 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Supported Versions/43 (5 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Post Handshake Auth/49) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Safe Renegotiation/65281) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Safe Renegotiation/65281 (1 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Server Name Indication/0) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Cookie/44) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Early Data/42) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (PSK Key Exchange Modes/45) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension PSK Key Exchange Modes/45 (3 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Record Size Limit/28) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Sending extension Record Size Limit/28 (2 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (ClientHello Padding/21) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Preparing extension (Pre Shared Key/41) for 'client hello' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: CLIENT HELLO was queued [328 bytes] Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Preparing Packet Handshake(22) with length: 328 and min pad: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 333 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 Feb 18 21:05:18 piranha kresd[6366]: [00000.00][plan] plan 'ogs.google.com.' type 'A' uid [08330.00] Feb 18 21:05:18 piranha kresd[6366]: [08330.00][iter] 'ogs.google.com.' type 'A' new uid was assigned .01, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.01][cach] => satisfied by exact CNAME: rank 030, new TTL 1005 Feb 18 21:05:18 piranha kresd[6366]: [08330.01][iter] <= rcode: NOERROR Feb 18 21:05:18 piranha kresd[6366]: [08330.01][iter] <= cname chain, following Feb 18 21:05:18 piranha kresd[6366]: [00000.00][plan] plan 'www3.l.google.com.' type 'A' uid [08330.02] Feb 18 21:05:18 piranha kresd[6366]: [08330.02][iter] 'www3.l.google.com.' type 'A' new uid was assigned .03, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.03][cach] => skipping exact RR: rank 030 (min. 030), new TTL -390 Feb 18 21:05:18 piranha kresd[6366]: [08330.03][cach] => no NSEC* cached for zone: google.com. Feb 18 21:05:18 piranha kresd[6366]: [08330.03][cach] => skipping zone: google.com., NSEC, hash 0;new TTL -123456789, ret -2 Feb 18 21:05:18 piranha kresd[6366]: [08330.03][cach] => skipping zone: google.com., NSEC, hash 0;new TTL -123456789, ret -2 Feb 18 21:05:18 piranha kresd[6366]: [08330.03][plan] plan '.' type 'DNSKEY' uid [08330.04] Feb 18 21:05:18 piranha kresd[6366]: [08330.04][iter] '.' type 'DNSKEY' new uid was assigned .05, parent uid .03 Feb 18 21:05:18 piranha kresd[6366]: [08330.05][cach] => satisfied by exact RRset: rank 060, new TTL 112006 Feb 18 21:05:18 piranha kresd[6366]: [08330.05][iter] <= rcode: NOERROR Feb 18 21:05:18 piranha kresd[6366]: [08330.05][vldr] <= parent: updating DNSKEY Feb 18 21:05:18 piranha kresd[6366]: [08330.05][vldr] <= answer valid, OK Feb 18 21:05:18 piranha kresd[6366]: [08330.03][iter] 'www3.l.google.com.' type 'A' new uid was assigned .06, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.06][plan] plan 'com.' type 'DS' uid [08330.07] Feb 18 21:05:18 piranha kresd[6366]: [08330.07][iter] 'com.' type 'DS' new uid was assigned .08, parent uid .06 Feb 18 21:05:18 piranha kresd[6366]: [08330.08][cach] => satisfied by exact RRset: rank 060, new TTL 30836 Feb 18 21:05:18 piranha kresd[6366]: [08330.08][iter] <= rcode: NOERROR Feb 18 21:05:18 piranha kresd[6366]: [08330.08][vldr] <= DS: OK Feb 18 21:05:18 piranha kresd[6366]: [08330.08][vldr] <= parent: updating DS Feb 18 21:05:18 piranha kresd[6366]: [08330.08][vldr] <= answer valid, OK Feb 18 21:05:18 piranha kresd[6366]: [08330.06][iter] 'www3.l.google.com.' type 'A' new uid was assigned .09, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.09][plan] plan 'com.' type 'DNSKEY' uid [08330.10] Feb 18 21:05:18 piranha kresd[6366]: [08330.10][iter] 'com.' type 'DNSKEY' new uid was assigned .11, parent uid .09 Feb 18 21:05:18 piranha kresd[6366]: [08330.11][cach] => satisfied by exact RRset: rank 060, new TTL 35081 Feb 18 21:05:18 piranha kresd[6366]: [08330.11][iter] <= rcode: NOERROR Feb 18 21:05:18 piranha kresd[6366]: [08330.11][vldr] <= parent: updating DNSKEY Feb 18 21:05:18 piranha kresd[6366]: [08330.11][vldr] <= answer valid, OK Feb 18 21:05:18 piranha kresd[6366]: [08330.09][iter] 'www3.l.google.com.' type 'A' new uid was assigned .12, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.12][plan] plan 'google.com.' type 'DS' uid [08330.13] Feb 18 21:05:18 piranha kresd[6366]: [08330.13][iter] 'google.com.' type 'DS' new uid was assigned .14, parent uid .12 Feb 18 21:05:18 piranha kresd[6366]: [08330.14][cach] => satisfied by exact packet: rank 060, new TTL 587 Feb 18 21:05:18 piranha kresd[6366]: [08330.14][iter] <= rcode: NOERROR Feb 18 21:05:18 piranha kresd[6366]: [08330.14][vldr] <= DS doesn't exist, going insecure Feb 18 21:05:18 piranha kresd[6366]: [08330.14][vldr] <= parent: updating DS Feb 18 21:05:18 piranha kresd[6366]: [08330.14][vldr] <= answer valid, OK Feb 18 21:05:18 piranha kresd[6366]: [08330.12][iter] 'www3.l.google.com.' type 'A' new uid was assigned .15, parent uid .00 Feb 18 21:05:18 piranha kresd[6366]: [08330.15][plan] plan 'google.com.' type 'NS' uid [08330.16] Feb 18 21:05:18 piranha kresd[6366]: [08330.16][iter] 'google.com.' type 'NS' new uid was assigned .17, parent uid .15 Feb 18 21:05:18 piranha kresd[6366]: [08330.17][cach] => skipping exact RR: rank 020 (min. 030), new TTL 4782 Feb 18 21:05:18 piranha kresd[6366]: [08330.17][cach] => no NSEC* cached for zone: google.com. Feb 18 21:05:18 piranha kresd[6366]: [08330.17][cach] => skipping zone: google.com., NSEC, hash 0;new TTL -123456789, ret -2 Feb 18 21:05:18 piranha kresd[6366]: [08330.17][cach] => skipping zone: google.com., NSEC, hash 0;new TTL -123456789, ret -2 Feb 18 21:05:18 piranha kresd[6366]: [ ][nsre] score 21 for 9.9.9.9#00853;#011 cached RTT: 25 Feb 18 21:05:18 piranha kresd[6366]: [08330.17][resl] => id: '21366' querying: '9.9.9.9#00853' score: 21 zone cut: 'com.' qname: 'gOogLe.Com.' qtype: 'NS' proto: 'tcp' Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Handshake packet received. Epoch 0, length: 123 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Handshake(22) with length: 123 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[0] Handshake(22) with length: 123 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: SERVER HELLO (2) was received. Length 119[119], frag offset 0, frag length: 119, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1162 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1413 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: Server's version: 3.3 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Parsing extension 'Supported Versions/43' (2 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Negotiated version: 3.4 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: Selected cipher suite: GNUTLS_AES_256_GCM_SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Parsing extension 'Key Share/51' (69 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: Selected group SECP256R1 (2) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (2) EXT[0x5589285527f0]: client generated SECP256R1 shared key Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Preparing Packet ChangeCipherSpec(20) with length: 1 and min pad: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Sent Packet[2] ChangeCipherSpec(20) in epoch 0 and length: 6 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) REC[0x5589285527f0]: Sent ChangeCipherSpec Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Initializing epoch #1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Epoch #1 ready Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: TLS 1.3 re-key with cipher suite: GNUTLS_AES_256_GCM_SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 ChangeCipherSpec packet received. Epoch 1, length: 1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet ChangeCipherSpec(20) with length: 1 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 39 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 39 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[0] Handshake(22) with length: 22 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: ENCRYPTED EXTENSIONS (8) was received. Length 18[18], frag offset 0, frag length: 18, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: parsing encrypted extensions Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) EXT[0x5589285527f0]: Parsing extension 'Supported Groups/10' (12 bytes) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 2664 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 2664 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:617 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1316 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/tls13/certificate_request.c[_gnutls13_recv_certificate_request]:204 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 2664 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 2664 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[1] Handshake(22) with length: 2647 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: CERTIFICATE (11) was received. Length 2643[2643], frag offset 0, frag length: 2643, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1162 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1413 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: parsing certificate message Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 97 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 97 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:617 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1316 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/tls13/certificate_verify.c[_gnutls13_recv_certificate_verify]:75 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 97 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 97 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[2] Handshake(22) with length: 80 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: CERTIFICATE VERIFY (15) was received. Length 76[76], frag offset 0, frag length: 76, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: Parsing certificate verify Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: verifying TLS 1.3 handshake data using ECDSA-SECP256R1-SHA256 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/ocsp-api.c[gnutls_ocsp_status_request_get2]:99 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/ocsp-api.c[gnutls_ocsp_status_request_get2]:99 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../../lib/x509/name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../../lib/x509/name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 1, length: 69 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Handshake(22) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 69 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[3] Handshake(22) with length: 52 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: FINISHED (20) was received. Length 48[48], frag offset 0, frag length: 48, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: parsing finished Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: sending finished Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: FINISHED was queued [52 bytes] Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Preparing Packet Handshake(22) with length: 52 and min pad: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Sent Packet[1] Handshake(22) in epoch 1 and length: 74 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/constate.c[_gnutls_epoch_get]:906 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Allocating epoch #2 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Initializing epoch #2 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Epoch #2 ready Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: TLS 1.3 re-key with cipher suite: GNUTLS_AES_256_GCM_SHA384 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Start of epoch cleanup Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Epoch #0 freed Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Epoch #1 freed Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: End of epoch cleanup Feb 18 21:05:18 piranha kresd[6366]: [tls_client] TLS handshake with 9.9.9.9#00853 has completed Feb 18 21:05:18 piranha kresd[6366]: [tls_client] TLS session has not resumed Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Preparing Packet Application Data(23) with length: 41 and min pad: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Sent Packet[1] Application Data(23) in epoch 2 and length: 63 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Preparing Packet Application Data(23) with length: 41 and min pad: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Sent Packet[2] Application Data(23) in epoch 2 and length: 63 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 2, length: 74 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Application Data(23) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 74 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[0] Handshake(22) with length: 57 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: NEW SESSION TICKET (4) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1431 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: parsing session ticket message Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1567 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 2, length: 74 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Application Data(23) Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 74 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Decrypted Packet[1] Handshake(22) with length: 57 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: NEW SESSION TICKET (4) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1431 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (4) HSK[0x5589285527f0]: parsing session ticket message Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1567 Feb 18 21:05:18 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 18 21:05:20 piranha kresd[6366]: [tls] session ticket: epoch 378545, scheduling rotation check in 4095999 ms Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 2, length: 19 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Application Data(23) Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 19 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../../../lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/crypto-api.c[gnutls_aead_cipher_decrypt]:714 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/cipher.c[decrypt_packet_tls13]:873 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/cipher.c[_gnutls_decrypt]:160 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1468 Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (1) Discarded message[2] due to invalid decryption Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 18 21:05:20 piranha kresd[6366]: [tls_client] gnutls_record_recv failed: GNUTLS_E_DECRYPTION_FAILED (-24) Feb 18 21:05:20 piranha kresd[6366]: [io] => connection to '9.9.9.9#00853' closed by peer (end of file) ``` ## Version of gnutls used: gnutls 3.6.6-2 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian Buster ## How reproducible: Steps to Reproduce: /etc/knot-resolver/kresd.conf ``` user('knot-resolver','knot-resolver') verbose(true) cache.size = 512*MB modules = { 'policy', 'view', 'hints', 'serve_stale < cache', 'workarounds < iterate', 'stats', 'predict' } view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end) view:addr('[::1]/128', function (req, qry) return policy.PASS end) view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end) policy.add(policy.all(policy.TLS_FORWARD({ { '9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt' }, }))) predict.config(20, 72) ``` ``` $ namebench 127.0.0.1 -x -O ``` ## Actual results: Many errors GNUTLS_E_DECRYPTION_FAILED in syslog ## Expected results: No errors -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 18 21:44:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 18 Feb 2019 20:44:08 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: Added a test, but I am not convinced if those starttls-* tests are working as expected. You can remove starting gnutls-serv without changing the result. There are different errors from gnutls-cli, but the script always `exit 0`. Please review and tell why my assumption is wrong. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_142437899 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:17:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:17:27 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: Do you see that if you disable hardware accelaration? I.e., set `GNUTLS_CPUID_OVERRIDE=1`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142558744 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:17:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:17:36 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:20:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:20:19 +0000 Subject: [gnutls-devel] GnuTLS | check_if_signed: Get source branch if not set (!930) In-Reply-To: References: Message-ID: Merge Request !930 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/930 Project:Branches: rockdaboot/gnutls:tmp-get-source-branch to gnutls/gnutls:master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/930 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:20:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:20:24 +0000 Subject: [gnutls-devel] GnuTLS | check_if_signed: Get source branch if not set (!930) In-Reply-To: References: Message-ID: Merge Request !930 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/930 Project:Branches: rockdaboot/gnutls:tmp-get-source-branch to gnutls/gnutls:master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/930 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:20:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:20:30 +0000 Subject: [gnutls-devel] GnuTLS | check_if_signed: Get source branch if not set (!930) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/930#note_142559405 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 08:21:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 07:21:05 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Merged. @chouquette if you rebase on master it should be addressed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142559531 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 09:58:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 08:58:04 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Rebased -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142613973 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 09:58:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 08:58:56 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: Rebased over master, as !930 was merged -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142614283 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 10:08:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 09:08:59 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: I quickly tried kresd 3.2.1 with gnutls 3.6.6 (though not on Debian) against Quad9 and CloudFlare and couldn't get this error within about a million requests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142622684 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 10:24:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 09:24:20 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Didn't seem to help, FWIW that's the output on my local branch: ``` chouquette at nibbler devel/check_if_signed target=master source= branch=thread_local_msvc chouquette at nibbler echo $? 0 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142628372 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 10:37:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 09:37:02 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: The commit check fails again... I imported your branch here and can't reproduce it locally. I even pushed it to my own Gitlab GnuTLS repo - and it succeeds. There is something weird going on with your repo. You should remove it and fork it again. But before, let's do some more tests if you have the patience (I am sorry for that). Please `git am check.patch` the attached file into your branch and `git push` it. It has some more output that should show what exactly is going wrong. [check.patch](/uploads/32d402fa4273ff4cae55b919e5a1b4e4/check.patch) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142633063 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 10:41:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 09:41:17 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Please see my comment at !931 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929#note_142634558 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 10:59:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 09:59:05 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: Patch applied here, do you want me to push it to the other branch as well? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142641534 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 11:18:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 10:18:02 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: No thanks. From the output I can see that the git structure deviates from what we have in the main repo. The number of commits between `master` and `HEAD` should be two (you made two commits to this branch). But `git rev-list` lists a huge amount of commits. This list includes some older commits where indeed the author and the Signed-off-by are different. So the check script is working correctly. I suggest to save your work/branches, remove the Gitlab gnutls repo (and your local copy), fork+clone the main repo again, recreate+push your branches again. If it's just about the two MRs, we can pull them in and push them to the main repo. That only makes sense if you (and the reviewer) consider them as ready-to-merge. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142649089 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 11:22:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 10:22:50 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: Just pushed both branches to upstream, you can view the pipelines at https://gitlab.com/gnutls/gnutls/pipelines. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142650903 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 11:52:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 10:52:36 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: I guess I can remove everything and reclone, but I'd prefer to understand what I did wrong. My best guess is that the MR used to be based on origin/gnutls_3_6_6 and was then rebased over origin/master After `git fsck` the output of `git rev-list` matches what it should. Could it be that my fork as the default git strategy (ie `git fetch`), which could have caused some old ancestors to show up when running `git rev-list` ? Thanks for pushing clean branches to upstream! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142663069 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 12:29:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 11:29:08 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: > After git fsck the output of git rev-list matches what it should. That is interesting to know. I never used `git fsck`. > Could it be that my fork as the default git strategy (ie git fetch), which could have caused some old ancestors to show up when running git rev-list ? It looks like that, but I can just guess. My git strategy is that my Gitlab.com clone is 'origin' and I have the upstream repo as remote (called 'upstream'). I never work on master, and create each working branch based on master (e.g. `git checkout master; git checkout -b new-branch`). To be up-to-date I regularly `git checkout master; git pull --all --prune; git merge --ff-only upstream/master; git push`. After that it's straight forward to rebase a branch / MR with `git checkout mr-branch; git rebase master; git push --force-with-lease`. So far, I never had an issue with that through all my project clones. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142675994 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 14:44:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 13:44:01 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: I did a direct checkout of https://gitlab.com/gnutls/gnutls/tree/tmp-update-ax-code-coverage and compilation went through in msys2 for both targets :+1: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_142730552 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 14:51:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 13:51:02 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: @chouquette There is an error in tests/conv-utf-8: https://gitlab.com/gnutls/gnutls/-/jobs/163792822/artifacts/file/build/tests/conv-utf8.log ``` [==========] Running 11 test(s). [ RUN ] check_utf8_fail1 [ OK ] check_utf8_fail1 [ RUN ] check_utf8_fail2 [ OK ] check_utf8_fail2 [ RUN ] check_utf16_fail1 [ OK ] check_utf16_fail1 [ RUN ] check_utf8_ok1 [ ERROR ] --- difference at offset 0 0x00 0x61 difference at offset 1 0x61 0x00 difference at offset 2 0x00 0x62 difference at offset 3 0x62 0x00 difference at offset 4 0x00 0x63 difference at offset 5 0x63 0x00 difference at offset 6 0x00 0x64 difference at offset 7 0x64 0x00 8 bytes of 0x7ffefc50 and 0x7f04f3a8 differ [ LINE ] --- ../../tests/conv-utf8.c:101: error: Failure! got: 6100620063006400 expected: 0061006200630064 [ FAILED ] check_utf8_ok1 [ RUN ] check_utf8_ok2 [ ERROR ] --- difference at offset 0 0x30 0xffffffe6 difference at offset 1 0xffffffe6 0x30 difference at offset 2 0x30 0xfffffffc difference at offset 3 0xfffffffc 0x30 difference at offset 4 0x30 0xffffffb6 difference at offset 5 0xffffffb6 0x30 difference at offset 6 0x30 0xfffffffc difference at offset 7 0xfffffffc 0x30 difference at offset 8 0x52 0x25 difference at offset 9 0x25 0x52 difference at offset 10 0x30 0xffffffb5 difference at offset 11 0xffffffb5 0x30 difference at offset 12 0x30 0xffffffa4 difference at offset 13 0xffffffa4 0x30 difference at offset 14 0x30 0xffffffc8 difference at offset 15 0xffffffc8 0x30 ... 16 bytes of 0x7ffefb2c and 0x7f0618e0 differ [ LINE ] --- ../../tests/conv-utf8.c:102: error: Failure! got: e630fc30b630fc302552b530a430c830 expected: 30e630fc30b630fc522530b530a430c8 [ FAILED ] check_utf8_ok2 [ RUN ] check_utf8_ok3 [ ERROR ] --- difference at offset 0 0x7b 0xffffff80 difference at offset 1 0xffffff80 0x7b difference at offset 2 0x4f 0x53 difference at offset 3 0x53 0x4f difference at offset 4 0x4e 0x2d difference at offset 5 0x2d 0x4e difference at offset 6 0x65 0xffffff87 difference at offset 7 0xffffff87 0x65 8 bytes of 0x7ffefb10 and 0x7f061618 differ [ LINE ] --- ../../tests/conv-utf8.c:103: error: Failure! got: 807b534f2d4e8765 expected: 7b804f534e2d6587 [ FAILED ] check_utf8_ok3 [ RUN ] check_utf8_ok4 [ ERROR ] --- difference at offset 0 0x03 0xffffffa3 difference at offset 1 0xffffffa3 0x03 difference at offset 2 0x1f 0x72 difference at offset 3 0x72 0x1f difference at offset 4 0x00 0x20 difference at offset 5 0x20 0x00 difference at offset 6 0x03 0xffffffb3 difference at offset 7 0xffffffb3 0x03 difference at offset 8 0x03 0xffffffbd difference at offset 9 0xffffffbd 0x03 difference at offset 10 0x03 0xffffffc9 difference at offset 11 0xffffffc9 0x03 difference at offset 12 0x03 0xffffffc1 difference at offset 13 0xffffffc1 0x03 difference at offset 14 0x03 0xffffffaf difference at offset 15 0xffffffaf 0x03 ... 28 bytes of 0x7ffefc30 and 0x7f061eb0 differ [ LINE ] --- ../../tests/conv-utf8.c:104: error: Failure! got: a303721f2000b303bd03c903c103af03b603c9032000001fc003781f expected: 03a31f72002003b303bd03c903c103af03b603c900201f0003c01f78 [ FAILED ] check_utf8_ok4 [ RUN ] check_utf16_ok1 [ OK ] check_utf16_ok1 [ RUN ] check_utf16_ok2 [ OK ] check_utf16_ok2 [ RUN ] check_utf16_ok3 [ OK ] check_utf16_ok3 [ RUN ] check_utf16_ok4 [ OK ] check_utf16_ok4 [==========] 11 test(s) run. [ PASSED ] 7 test(s). [ FAILED ] 4 test(s), listed below: [ FAILED ] check_utf8_ok1 [ FAILED ] check_utf8_ok2 [ FAILED ] check_utf8_ok3 [ FAILED ] check_utf8_ok4 4 FAILED TEST(S) FAIL conv-utf8 (exit status: 4) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142733567 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 20:50:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 19:50:15 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/includes/gnutls/gnutls.h.in: > extern _SYM_EXPORT gnutls_calloc_function gnutls_calloc; > extern _SYM_EXPORT gnutls_free_function gnutls_free; > > +#ifdef GNUTLS_INTERNAL_BUILD We are using `gnutls_int.h` only in `lib/`, not in `src/`. This MR is also about code in `src/`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_142868020 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 20:55:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 19:55:57 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/x509/pkcs12_bag.c: > _gnutls_free_datum(&bag->element[i].data); Yes it does. Sorry I don't get the point - please explain. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_142869645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 21:55:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 20:55:11 +0000 Subject: [gnutls-devel] GnuTLS | tests/memset[01] failing with valgrind on Debian unstable (#708) References: Message-ID: New Issue was created. Issue 708: https://gitlab.com/gnutls/gnutls/issues/708 Author: Tim R?hsen Assignee: Valgrind 3.14.0 / libc6 2.28 likely add some more stack memory protection, so that these tests fail. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/708 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 22:06:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 21:06:15 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: It still fails to decrypt it: ``` Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: End of epoch cleanup Feb 19 22:01:46 piranha kresd[15127]: [tls_client] TLS handshake with 2620:fe::fe#00853 has completed Feb 19 22:01:46 piranha kresd[15127]: [tls_client] TLS session has not resumed Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Preparing Packet Application Data(23) with length: 40 and min pad: 0 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Sent Packet[1] Application Data(23) in epoch 2 and length: 62 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: SSL 3.3 Application Data packet received. Epoch 2, length: 74 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Expected Packet Application Data(23) Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Received Packet Application Data(23) with length: 74 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Decrypted Packet[0] Handshake(22) with length: 57 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/buffers.c[get_last_packet]:1171 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (4) HSK[0x560dad8cef80]: NEW SESSION TICKET (4) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1431 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (4) HSK[0x560dad8cef80]: parsing session ticket message Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1567 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: SSL 3.3 Application Data packet received. Epoch 2, length: 73 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Expected Packet Application Data(23) Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (5) REC[0x560dad8cef80]: Received Packet Application Data(23) with length: 73 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../../lib/nettle/cipher.c[wrap_nettle_cipher_aead_decrypt]:880 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/crypto-api.c[gnutls_aead_cipher_decrypt]:714 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/cipher.c[decrypt_packet_tls13]:873 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/cipher.c[_gnutls_decrypt]:160 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1468 Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (1) Discarded message[1] due to invalid decryption Feb 19 22:01:46 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766 Feb 19 22:01:46 piranha kresd[15127]: [tls_client] gnutls_record_recv failed: GNUTLS_E_DECRYPTION_FAILED (-24) Feb 19 22:01:48 piranha kresd[15127]: [gnutls] (3) ASSERT: ../../lib/record.c[check_session_status]:1639 Feb 19 22:01:48 piranha kresd[15127]: [tls_client] gnutls_record_recv failed: GNUTLS_E_INVALID_SESSION (-10) Feb 19 22:01:48 piranha kresd[15127]: [io] => connection to '2620:fe::fe#00853' closed by peer (end of file) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142900885 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 22:15:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 21:15:46 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: Different TLS works fine on the network, right? (e.g. https) Or ideally if you could test TLS forwarding from some other SW that doesn't use gnutls, e.g. unbound. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142903652 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 22:24:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 21:24:19 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: I cannot remember seeing problems while browsing HTTPS sites. I also use OpenVPN client from time to time (which is linked with libssl), and it works fine. There might be a hardware problem though (PC sometimes randomly hangs). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142908955 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 19 22:28:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 19 Feb 2019 21:28:43 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: There were some bugs around Ryzen, at least early on. I can't recall any recent significant problem with _my piece_, though it used to be pretty annoying a year ago. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_142911047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:28:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:28:08 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Reduce capi usage (!840) In-Reply-To: References: Message-ID: Merge Request !840 was closed by Hugo Beauz?e-Luyssen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/840 Project:Branches: chouquette/gnutls:reduce_capi_usage to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/840 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:28:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:28:10 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!931) In-Reply-To: References: Message-ID: Merge Request !931 was closed by Hugo Beauz?e-Luyssen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/931 Project:Branches: chouquette/gnutls:use_topendir to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/931 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:28:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:28:08 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!929) In-Reply-To: References: Message-ID: Merge Request !929 was closed by Hugo Beauz?e-Luyssen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/929 Project:Branches: chouquette/gnutls:thread_local_msvc to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/929 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:34:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:34:38 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) References: Message-ID: New Merge Request !932 https://gitlab.com/gnutls/gnutls/merge_requests/932 Project:Branches: chouquette/gnutls:use_topendir_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: This is reintroducing the changes from !835 (merged) (and thus reverting those introducing in !860 (merged)) The failure was due to an incorrect byte order in the path provided to _topendir. I'm not sure if the 3rd patch is correct, there might be a macro/constant that can be use to express that the _gnutls_utf8_to_ucs2 caller wants native by order. Patch 2 & 3 might be better of squashed, but for the sake of reviewing, I think they're better of split for now. This is a basically a copy of !931 because of some git 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/932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:37:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:37:22 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Now the commit-check job is green, and this should also address the mips tests failure (https://gitlab.com/gnutls/gnutls/merge_requests/931#note_142733567) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143102149 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 20 11:39:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 20 Feb 2019 10:39:48 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!933) References: Message-ID: New Merge Request !933 https://gitlab.com/gnutls/gnutls/merge_requests/933 Project:Branches: chouquette/gnutls:thread_local_msvc_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: This is a copy of !929, with git issues fixed/worked around. ## 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/933 You're receiving 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 Feb 21 11:11:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 10:11:10 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { You could simplify the code using `while ((d = _treaddir(dirp)) != NULL) {`, and remove the extra `d != NULL)` check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143564852 You're receiving 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 Feb 21 11:13:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 10:13:14 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/x509/verify-high2.c: > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { > + d = _treaddir(dirp); > + if (d != NULL > +#ifdef _DIRENT_HAVE_D_TYPE > + && (d->d_type == DT_REG || d->d_type == DT_LNK || d->d_type == DT_UNKNOWN) > +#endif > + ) { > + snprintf(path, sizeof(path), "%s/%S", `%S` is tagged as 'don't use'. Since snprintf should be covered by gnulib, '%ls' is preferred. Can you check if that works for you ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143565811 You're receiving 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 Feb 21 11:14:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 10:14:06 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/x509/verify-high2.c: > + ) { > + snprintf(path, sizeof(path), "%s/%S", > + dirname, d->d_name); > + > + if (crl != 0) { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, NULL, path, type, tl_flags, > + tl_vflags); > + } else { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, path, NULL, type, tl_flags, > + tl_vflags); > + } > + if (ret >= 0) Doesn't `if (ret > 0)` make more sense here ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143566396 You're receiving 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 Feb 21 11:24:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 10:24:00 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/x509/verify-high2.c: > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { > + d = _treaddir(dirp); > + if (d != NULL > +#ifdef _DIRENT_HAVE_D_TYPE > + && (d->d_type == DT_REG || d->d_type == DT_LNK || d->d_type == DT_UNKNOWN) > +#endif > + ) { > + snprintf(path, sizeof(path), "%s/%S", Also, does mixing %s and %S makes sense ? Are wide chars converted to ASCII (or UTF-8) by %S ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143571751 You're receiving 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 Feb 21 14:16:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 13:16:03 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { Sure, I'll fix the other variant as well then, for consistency -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143637801 You're receiving 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 Feb 21 14:24:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 13:24:40 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { Hm, actually I don't think we can assume that closedir(NULL) is safe, so the `d != NULL` check must stay -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143640899 You're receiving 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 Feb 21 14:41:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 13:41:58 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { > + d = _treaddir(dirp); > + if (d != NULL > +#ifdef _DIRENT_HAVE_D_TYPE > + && (d->d_type == DT_REG || d->d_type == DT_LNK || d->d_type == DT_UNKNOWN) > +#endif > + ) { > + snprintf(path, sizeof(path), "%s/%S", My bad, I thought %S was covered by the standard, but it seems it's not. Regarding the 2nd part of your question, my understanding is that they are converted indeed ``` If an l length modifier is present, the argument shall be a pointer to the initial element of an array of wchar_t type. Wide characters from the array are converted to multibyte characters ``` N1548 - ?7.21.6.1 I'll make the change locally and will check with the testsuite -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143647305 You're receiving 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 Feb 21 14:52:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 13:52:19 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { Do you want this to be squashed in the revert commit? Or rather as a separate one? (I'll push a separate commit with your remarks for now, but I'll gladly squash all changes to the revert commit, or I can base myself on the original addition instead, if you think it would be clearer) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143651513 You're receiving 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 Feb 21 14:55:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 13:55:06 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > + ) { > + snprintf(path, sizeof(path), "%s/%S", > + dirname, d->d_name); > + > + if (crl != 0) { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, NULL, path, type, tl_flags, > + tl_vflags); > + } else { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, path, NULL, type, tl_flags, > + tl_vflags); > + } > + if (ret >= 0) It does, but that's also taken from the non UNICODE variant. I can add a patch to change that for both variants if you want -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143652559 You're receiving 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 Feb 21 15:01:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 14:01:16 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { squashing sounds good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143654968 You're receiving 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 Feb 21 15:03:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 14:03:05 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/x509/verify-high2.c: > + ) { > + snprintf(path, sizeof(path), "%s/%S", > + dirname, d->d_name); > + > + if (crl != 0) { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, NULL, path, type, tl_flags, > + tl_vflags); > + } else { > + ret = > + gnutls_x509_trust_list_add_trust_file > + (list, path, NULL, type, tl_flags, > + tl_vflags); > + } > + if (ret >= 0) As you like then, I just checked the new code (Gitlab just displays that). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143655660 You're receiving 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 Feb 21 15:05:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 14:05:46 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: All discussions on Merge Request !932 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/932 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932 You're receiving 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 Feb 21 15:20:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 14:20:57 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/x509/verify-high2.c: > while (d != NULL); > closedir(dirp); > } > +#else /* _WIN32 */ > > + _TDIR *dirp; > + struct _tdirent *d; > + gnutls_datum_t utf16 = {NULL, 0}; > + > + r = _gnutls_utf8_to_ucs2(dirname, strlen(dirname), &utf16); > + if (r < 0) > + return gnutls_assert_val(r); > + dirp = _topendir((_TCHAR*)utf16.data); > + gnutls_free(utf16.data); > + if (dirp != NULL) { > + do { Pushed a version with the patches squashed in the revert -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143662605 You're receiving 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 Feb 21 16:14:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 15:14:35 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: And re-pushed with the missing Signed-off, sorry about that. Out of curiosity, why do you require commits to be self-Signed-Off by? Isn't `Author:` enough for that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143692926 You're receiving 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 Feb 21 16:16:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 15:16:03 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Just one question (and sorry for being late - it just came to my mind): Did you test/check the gnulib emulation of opendir/readdir ? It uses FindFirstFile() / FindNextFile() which return path names as byte strings (ASCII / UTF-8). All you have to do is add opendir and readdir to the `gnulib_modules=` variable in `bootstrap.conf` followed by `./bootstrap && ./configure && ...`. It would reduce code duplication... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143693619 You're receiving 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 Feb 21 16:19:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 15:19:05 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: I guess @nmav has this in mind: https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143695037 You're receiving 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 Feb 21 18:06:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 17:06:58 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) References: Message-ID: New Issue was created. Issue 713: https://gitlab.com/gnutls/gnutls/issues/713 Author: Andreas Metzler Assignee: This is https://bugs.debian.org/922879 submitted by R?mi Denis-Courmont, I am as acting as proxy for R?mi: With GnuTLS 3.6.x, VLC pseudo-randomly fails to connect to HTTP/2 servers due to what seems like a race condition in GnuTLS. See also https://trac.videolan.org/vlc/ticket/21951 . To reproduce, run VLC a dozen time or so (depending on the system), until hitting a failure: ``` # vlc -Irc https://streams.videolan.org/issues/21941/Greatest%20Motown%20Songs%2060s%2070s%20Hits.mp3 (Ctrl+C to abort if it does not fail straight away) ``` The problem appears to be caused by the "fix" for Debian bug 849807 / #158 which does not seem to follow the GnuTLS thread safety rules. Since breaking working applications seems far worse than protecting broken applications from shooting themselves in the foot, I suggest reverting 849807 (i.e. GnuTLS commit 6a62ddfc416a4ec2118704f93c97fdd448d66566 ). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713 You're receiving 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 Feb 21 18:34:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 17:34:23 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: I must say haven't, but looking at the opendir implementation there I doubt it will work with wide characters (which we must use when compiling for UWP/WinRT platform), as the pattern is using regular ascii inputs, and `char` are used unconditionally. Good to know about the Signed-Off part! I always assumed this to be for other people to use, but I get the idea :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143744175 You're receiving 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 Feb 21 19:13:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:13:17 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!933) In-Reply-To: References: Message-ID: Merge Request !933 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/933 Project:Branches: chouquette/gnutls:thread_local_msvc_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/933 You're receiving 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 Feb 21 19:13:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:13:25 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!927) In-Reply-To: References: Message-ID: @nmav @rockdaboot Hi, I know these changes may be hard to merge directly, do you have any suggestions on improving these? Maybe we could add an option to redirect the output? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/927#note_143755743 You're receiving 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 Feb 21 19:13:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:13:50 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!933) In-Reply-To: References: Message-ID: Merge Request !933 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/933 Project:Branches: chouquette/gnutls:thread_local_msvc_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/933 You're receiving 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 Feb 21 19:14:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:14:02 +0000 Subject: [gnutls-devel] GnuTLS | lib: Provide _Thread_local on MSVC (!933) 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/933#note_143756590 You're receiving 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 Feb 21 19:21:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:21:57 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/x509/pkcs12_bag.c: > _gnutls_free_datum(&bag->element[i].data); My point was to simplify the function to not set the variable to NULL twice. You already did as I see. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_143761773 You're receiving 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 Feb 21 19:21:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:21:58 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: All discussions on Merge Request !923 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/923 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923 You're receiving 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 Feb 21 19:22:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:22:36 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: Issue was closed by Fred Issue #707: https://gitlab.com/gnutls/gnutls/issues/707 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707 You're receiving 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 Feb 21 19:22:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:22:36 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: Knot Resolver 3.2.1 entered Debian SID, and I cannot reproduce this problem any more with this version. The changelog of 3.2.1 mentions some TLS related bugfixes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_143761920 You're receiving 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 Feb 21 19:24:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:24:31 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Merge Request !923 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/923 Branches: tmp-reset-after-free to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923 You're receiving 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 Feb 21 19:24:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:24:45 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_143762459 You're receiving 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 Feb 21 19:25:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:25:34 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: I think it makes sense to add a NEWS entry about this change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_143762661 You're receiving 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 Feb 21 19:27:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:27:01 +0000 Subject: [gnutls-devel] GnuTLS | assert: lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351 (#707) In-Reply-To: References: Message-ID: It seems weird they would manifest _this_ way, but I guess we can abandon this issue if it doesn't happen anymore. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/707#note_143762950 You're receiving 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 Feb 21 19:42:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:42:27 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/supported_versions.c: > > _gnutls_handshake_log("EXT[%p]: Negotiated version: %d.%d\n", > session, (int)major, (int)minor); > + /* regenerate the random value to set The only drawback is that we generate the random bytes twice... but other than that it is quite clean. LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_143766249 You're receiving 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 Feb 21 19:47:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:47:51 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/tls13/rnd-check-rollback-val.c: > &server_key, > GNUTLS_X509_FMT_PEM); > > + gnutls_session_ticket_key_generate(&skey); a nitpick here, this and `gnutls_session_ticket_enable_server` within an assert will be safer -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_143767302 You're receiving 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 Feb 21 19:48:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:48:43 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: A NEWS entry will be helpful for this change. Other than the above, it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_143767495 You're receiving 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 Feb 21 19:48:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 21 Feb 2019 18:48:55 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Merge Request !918 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/918 Branches: tmp-downgrade-sentinel to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 08:52:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 07:52:37 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!927) In-Reply-To: References: Message-ID: Hi, Sorry for late reply. I think the options we have are: 1. delay any change to 3.7.0 and merge it then; because on such milestones we can break previous behavior more freely 2. as @npmccallum writes, introduce a new option which specifies a file to send the debug output to; this will have no side effect to existing applications I think (2) we can merge much more easily. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/927#note_143914941 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 08:57:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 07:57:48 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: Hi, Thank you for that. What is the actual issue here? Is vlc using one thread to perform the handshake and another to start transmitting? In that case is the transmitting thread starting after handshake is actually completed but before the sending thread CPU see the handshake completed variable change? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_143916476 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 08:59:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 07:59:43 +0000 Subject: [gnutls-devel] GnuTLS | tests/memset[01] failing with valgrind on Debian unstable (#708) In-Reply-To: References: Message-ID: These tests are ugly but validate whether `gnutls_memset` works as expected. They already avoid running under a memory sanitizer, so a solution would be to skip them when valgrind is detected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/708#note_143916941 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 09:04:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 08:04:37 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: The coverage calculation is done correctly, so it looks good to me (squashing the patches would be better I think). I only had a question which is inline. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_143918020 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 09:04:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 08:04:45 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on bootstrap.conf: > > # git -C ${GNULIB_SRCDIR} reset --hard > > + # needed for legacy (pre-2019) autoconf-archive > + touch aminclude_static.am is that still needed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_143917787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 10:17:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 09:17:22 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: Hi, The current theory is that due to false start, we end up having one thread initiating the handshake, and another thread that starts transmitting and therefor completing the handshake from that different thread. You can find a tentative patch, along with an early discussion here: https://patches.videolan.org/patch/22625/ (or here: https://mailman.videolan.org/pipermail/vlc-devel/2019-February/123053.html) Your comments/opinion on our understanding of the API is more than welcome! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_143963807 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 10:31:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 09:31:52 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on bootstrap.conf: > > # git -C ${GNULIB_SRCDIR} reset --hard > > + # needed for legacy (pre-2019) autoconf-archive > + touch aminclude_static.am Of course not :-) Removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_143968740 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 10:32:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 09:32:55 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Merged the changes into a single commit. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905#note_143969271 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 10:55:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 09:55:09 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: All discussions on Merge Request !918 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/918 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 10:55:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 09:55:03 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/supported_versions.c: > > _gnutls_handshake_log("EXT[%p]: Negotiated version: %d.%d\n", > session, (int)major, (int)minor); > + /* regenerate the random value to set True, I added the same check as in `_gnutls_user_hello_func` so that the random is generated only when the negotiated version is different to the previous one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918#note_143979489 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 11:19:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 10:19:58 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Added an entry to `NEWS`. Please review. BTW, we should introduce the same measurement basically for all `deinit` functions. Not doing so keeps a gap open. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_143991032 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 11:23:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 10:23:26 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Merge Request !932 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/932 Project:Branches: chouquette/gnutls:use_topendir_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 11:23:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 10:23:33 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Merge Request !932 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/932 Project:Branches: chouquette/gnutls:use_topendir_fixed to gnutls/gnutls:master Author: Hugo Beauz?e-Luyssen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 11:25:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 10:25:00 +0000 Subject: [gnutls-devel] GnuTLS | Re-introduce topendir on Windows with Unicode support (!932) In-Reply-To: References: Message-ID: Ok, since we can't test that, I rely on you :-) Thanks for your work ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/932#note_143993985 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 11:45:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 10:45:51 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) 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/918#note_144001646 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 12:42:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 11:42:29 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #689: https://gitlab.com/gnutls/gnutls/issues/689 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 12:42:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 11:42:28 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS sends TLS 1.3 downgrade sentinel in TLS 1.3 (#689) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #689: https://gitlab.com/gnutls/gnutls/issues/689 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/689 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 12:42:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 11:42:29 +0000 Subject: [gnutls-devel] GnuTLS | handshake: defer setting downgrade sentinel until version is selected (!918) In-Reply-To: References: Message-ID: Merge Request !918 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/918 Branches: tmp-downgrade-sentinel to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 13:03:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 12:03:41 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on NEWS: > > * Version 3.6.7 (unreleased) > > +** libgnutls, gnutls tools: Every gnutls_free() will automatically set > + the free'd pointer to NULL. This prevents possible use-after-free and > + double free issues. Use-after-free will be turned into NULL dereference, > + effectively turning harmful attacks like remote-code-executions (RCE) into What about finishing the text at: `will be turned into NULL dereference.` The `turned into NULL dereference, effectively turning harmful attacks like remote-code-executions (RCE) into segmentation faults` text, seems to imply that this is not exploitable, but that's hard to prove as it depends on the application. That is, what about: ``` * libgnutls, gnutls tools: Every gnutls_free() will automatically set the free'd pointer to NULL. This prevents possible use-after-free and double free issues. Use-after-free will be turned into NULL dereference. The counter-measure does not extend to applications using `gnutls_free`. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_144026098 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 13:11:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 12:11:58 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Sounds good to me. Pushed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_144028369 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 14:29:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 13:29:08 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: All discussions on Merge Request !923 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/923 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 14:30:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 13:30:24 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: All discussions on Merge Request !905 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/905 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 14:35:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 13:35:05 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Merge Request !905 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/905 Branches: tmp-update-ax-code-coverage to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 14:35:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 13:35:40 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) 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/905#note_144063462 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 14:53:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 13:53:26 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli --benchmark type overflow on 32 bit arch (#685) In-Reply-To: References: Message-ID: Would you or Hiroyuki would like to submit a MR replacing the long with uint64_t? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/685#note_144070199 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 15:14:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 14:14:37 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: All discussions on Merge Request !911 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/911 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 15:24:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 14:24:47 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: > BTW, `starttls-pop3.sh` starts `gnutls-serv` - what for ??? Removing it doesn't change a thing. Does it? I see it starting socat server. The logic is a lit strange, but it opens a socat server which will chat the protocol in question. If the negotiation of the starttls protocol fails gnutls-cli will return 2 as error code, and that's what the script is waiting for to detect failure. exit code 1 means that the handshake or something else has failed, and that's expected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_144083816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 15:27:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 14:27:43 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: If I modify the script for the server to send something else than the expected, it seems to fail, isn't that right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_144084842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 15:39:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 14:39:09 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: The server fails, but the test script exits with $? being 0 (at least here). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_144089231 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 15:39:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 14:39:48 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: ``` WARNING: ThreadSanitizer: data race (pid=636) Read of size 4 at 0x7b8c00012014 by thread T11: #0 gnutls_record_send2 /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1983 (libgnutls_plugin.so+0x20c52) #1 gnutls_record_send /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1944 (libgnutls_plugin.so+0x21115) #2 gnutls_Send ../../modules/misc/gnutls.c:175 (libgnutls_plugin.so+0x197f3) #3 vlc_https_send ../../modules/access/http/h2output.c:204 (libhttps_plugin.so+0xfddd) #4 vlc_h2_frame_send ../../modules/access/http/h2output.c:250 (libhttps_plugin.so+0xffdc) #5 vlc_h2_output_thread ../../modules/access/http/h2output.c:265 (libhttps_plugin.so+0x1006d) #6 vlc_h2_client_output_thread ../../modules/access/http/h2output.c:299 (libhttps_plugin.so+0x101fb) #7 (libtsan.so.0+0x29b4d) Previous write of size 4 at 0x7b8c00012014 by thread T12: #0 check_session_status /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1690 (libgnutls_plugin.so+0x20204) #1 _gnutls_recv_int /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1753 (libgnutls_plugin.so+0x2055c) #2 gnutls_record_recv /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:2261 (libgnutls_plugin.so+0x215ca) #3 gnutls_Recv ../../modules/misc/gnutls.c:146 (libgnutls_plugin.so+0x196d0) #4 vlc_https_recv ../../modules/access/http/h2conn.c:563 (libhttps_plugin.so+0x122c4) #5 vlc_h2_frame_recv ../../modules/access/http/h2conn.c:606 (libhttps_plugin.so+0x12453) #6 vlc_h2_recv_thread ../../modules/access/http/h2conn.c:656 (libhttps_plugin.so+0x1270d) #7 (libtsan.so.0+0x29b4d) Location is heap block of size 6504 at 0x7b8c00011800 allocated by thread T5: #0 calloc (libtsan.so.0+0x2b333) #1 gnutls_init /home/chouquette/dev/vlc/contrib/native/gnutls/lib/state.c:450 (libgnutls_plugin.so+0x63a18) #2 gnutls_SessionOpen ../../modules/misc/gnutls.c:241 (libgnutls_plugin.so+0x199fe) #3 gnutls_ClientSessionOpen ../../modules/misc/gnutls.c:386 (libgnutls_plugin.so+0x1a22c) #4 vlc_tls_ClientSessionCreate ../../src/network/tls.c:151 (libvlccore.so.9+0x165aac) #5 vlc_tls_SocketOpenTLS ../../src/network/tls.c:242 (libvlccore.so.9+0x16607d) #6 vlc_https_connect ../../modules/access/http/connmgr.c:65 (libhttps_plugin.so+0x15662) #7 vlc_https_request ../../modules/access/http/connmgr.c:175 (libhttps_plugin.so+0x15b3d) #8 vlc_http_mgr_request ../../modules/access/http/connmgr.c:258 (libhttps_plugin.so+0x15f2a) #9 vlc_http_res_open ../../modules/access/http/resource.c:93 (libhttps_plugin.so+0x90c0) #10 vlc_http_res_get_status ../../modules/access/http/resource.c:138 (libhttps_plugin.so+0x92aa) #11 Open ../../modules/access/http/access.c:206 (libhttps_plugin.so+0x47df) #12 generic_start ../../src/modules/modules.c:320 (libvlccore.so.9+0x8dcde) #13 module_load ../../src/modules/modules.c:167 (libvlccore.so.9+0x8d4a0) #14 vlc_module_load ../../src/modules/modules.c:244 (libvlccore.so.9+0x8d84f) #15 module_need ../../src/modules/modules.c:335 (libvlccore.so.9+0x8de38) #16 access_New ../../src/input/access.c:149 (libvlccore.so.9+0xc098e) #17 stream_AccessNew ../../src/input/access.c:294 (libvlccore.so.9+0xc12ed) #18 InputDemuxNew ../../src/input/input.c:2518 (libvlccore.so.9+0xfe90c) #19 InputSourceNew ../../src/input/input.c:2659 (libvlccore.so.9+0xff26b) #20 Init ../../src/input/input.c:1362 (libvlccore.so.9+0xf9b74) #21 Run ../../src/input/input.c:532 (libvlccore.so.9+0xf62fe) #22 (libtsan.so.0+0x29b4d) Thread T11 (tid=649, running) created by thread T5 at: #0 pthread_create (libtsan.so.0+0x2be2b) #1 vlc_clone_attr ../../src/posix/thread.c:421 (libvlccore.so.9+0x1a2936) #2 vlc_clone ../../src/posix/thread.c:433 (libvlccore.so.9+0x1a29c3) #3 vlc_h2_output_create ../../modules/access/http/h2output.c:323 (libhttps_plugin.so+0x10388) #4 vlc_h2_conn_create ../../modules/access/http/h2conn.c:730 (libhttps_plugin.so+0x12ad3) #5 vlc_https_request ../../modules/access/http/connmgr.c:190 (libhttps_plugin.so+0x15b88) #6 vlc_http_mgr_request ../../modules/access/http/connmgr.c:258 (libhttps_plugin.so+0x15f2a) #7 vlc_http_res_open ../../modules/access/http/resource.c:93 (libhttps_plugin.so+0x90c0) #8 vlc_http_res_get_status ../../modules/access/http/resource.c:138 (libhttps_plugin.so+0x92aa) #9 Open ../../modules/access/http/access.c:206 (libhttps_plugin.so+0x47df) #10 generic_start ../../src/modules/modules.c:320 (libvlccore.so.9+0x8dcde) #11 module_load ../../src/modules/modules.c:167 (libvlccore.so.9+0x8d4a0) #12 vlc_module_load ../../src/modules/modules.c:244 (libvlccore.so.9+0x8d84f) #13 module_need ../../src/modules/modules.c:335 (libvlccore.so.9+0x8de38) #14 access_New ../../src/input/access.c:149 (libvlccore.so.9+0xc098e) #15 stream_AccessNew ../../src/input/access.c:294 (libvlccore.so.9+0xc12ed) #16 InputDemuxNew ../../src/input/input.c:2518 (libvlccore.so.9+0xfe90c) #17 InputSourceNew ../../src/input/input.c:2659 (libvlccore.so.9+0xff26b) #18 Init ../../src/input/input.c:1362 (libvlccore.so.9+0xf9b74) #19 Run ../../src/input/input.c:532 (libvlccore.so.9+0xf62fe) #20 (libtsan.so.0+0x29b4d) Thread T12 (tid=650, running) created by thread T5 at: #0 pthread_create (libtsan.so.0+0x2be2b) #1 vlc_clone_attr ../../src/posix/thread.c:421 (libvlccore.so.9+0x1a2936) #2 vlc_clone ../../src/posix/thread.c:433 (libvlccore.so.9+0x1a29c3) #3 vlc_h2_conn_create ../../modules/access/http/h2conn.c:742 (libhttps_plugin.so+0x12bce) #4 vlc_https_request ../../modules/access/http/connmgr.c:190 (libhttps_plugin.so+0x15b88) #5 vlc_http_mgr_request ../../modules/access/http/connmgr.c:258 (libhttps_plugin.so+0x15f2a) #6 vlc_http_res_open ../../modules/access/http/resource.c:93 (libhttps_plugin.so+0x90c0) #7 vlc_http_res_get_status ../../modules/access/http/resource.c:138 (libhttps_plugin.so+0x92aa) #8 Open ../../modules/access/http/access.c:206 (libhttps_plugin.so+0x47df) #9 generic_start ../../src/modules/modules.c:320 (libvlccore.so.9+0x8dcde) #10 module_load ../../src/modules/modules.c:167 (libvlccore.so.9+0x8d4a0) #11 vlc_module_load ../../src/modules/modules.c:244 (libvlccore.so.9+0x8d84f) #12 module_need ../../src/modules/modules.c:335 (libvlccore.so.9+0x8de38) #13 access_New ../../src/input/access.c:149 (libvlccore.so.9+0xc098e) #14 stream_AccessNew ../../src/input/access.c:294 (libvlccore.so.9+0xc12ed) #15 InputDemuxNew ../../src/input/input.c:2518 (libvlccore.so.9+0xfe90c) #16 InputSourceNew ../../src/input/input.c:2659 (libvlccore.so.9+0xff26b) #17 Init ../../src/input/input.c:1362 (libvlccore.so.9+0xf9b74) #18 Run ../../src/input/input.c:532 (libvlccore.so.9+0xf62fe) #19 (libtsan.so.0+0x29b4d) Thread T5 (tid=642, running) created by thread T2 at: #0 pthread_create (libtsan.so.0+0x2be2b) #1 vlc_clone_attr ../../src/posix/thread.c:421 (libvlccore.so.9+0x1a2936) #2 vlc_clone ../../src/posix/thread.c:433 (libvlccore.so.9+0x1a29c3) #3 input_Start ../../src/input/input.c:192 (libvlccore.so.9+0xf4eff) #4 PlayItem ../../src/playlist_legacy/thread.c:242 (libvlccore.so.9+0x9bb36) #5 Next ../../src/playlist_legacy/thread.c:482 (libvlccore.so.9+0x9cc51) #6 Thread ../../src/playlist_legacy/thread.c:507 (libvlccore.so.9+0x9cd68) #7 (libtsan.so.0+0x29b4d) ``` Since the lines may not be accurate when taken from our contrib build (at least they weren't, compared to my local gnutls repo), here are the read/writes incriminated in the race/bug: read: ``` if (unlikely(!session->internals.initial_negotiation_completed)) { /* this is to protect buggy applications from sending unencrypted * data. We allow sending however, if we are in false start handshake * state. */ if (session->internals.recv_state != RECV_STATE_FALSE_START && // <--------------- session->internals.recv_state != RECV_STATE_EARLY_START && !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) return gnutls_assert_val(GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE); } ``` Which is the code added by https://gitlab.com/gnutls/gnutls/commit/6a62ddfc416a4ec2118704f93c97fdd448d66566 Write: record.c ``` case RECV_STATE_FALSE_START: /* if false start is not complete we always expect for handshake packets * prior to anything else. */ if (session->security_parameters.entity != GNUTLS_CLIENT || !(session->internals.flags & GNUTLS_ENABLE_FALSE_START)) return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); /* Attempt to complete handshake */ session->internals.recv_state = RECV_STATE_FALSE_START_HANDLING; // <---------------- ret = gnutls_handshake(session); if (ret < 0) { /* a temp or fatal error, make sure we reset the state * so we can resume on temp errors */ session->internals.recv_state = RECV_STATE_FALSE_START; return gnutls_assert_val(ret); } ``` The 2 threads racing are our http2 stack receiver thread (`T11`), and sender thread (`T12`) If VLC's usage of the API is correct, then accesses to the session's internals must be made atomic, or we need to add some synchronization on our end if it's our job to ensure the handshake ran to completion after a fast start during recv/send But in any case, as things stand, the current code/use of the API is not thread safe. I'll happily provide a patch, but should the fix be in GnuTLS, I could use some guidance :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144089452 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:15:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:15:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:21:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:21:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: Aha, interesting. I think that's what I mentioned in the mail, when false start is enabled you cannot be sending and receiving at the same time on two threads. That's because the handshake process, may need to send while operation is receive or receive while operation is send. Maybe the patch could be a clarification that false start and early start (applies to tls1.3 servers), cannot be used by concurrent sending and receiving applications without some synchronization. The synchronization could be locking on recv and send operations, until the handshake is complete. The handshake in false start and early start is complete when a recv operation is complete. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144102801 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:27:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:27:48 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: but the failure should be detected on gnutls-cli right? If the chat fails to do the right communication what we need is for gnutls-cli to detect it and return with exit code 2. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_144104866 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:33:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:33:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: > Maybe the patch could be a clarification that false start and early start (applies to tls1.3 servers), cannot be used by concurrent sending and receiving applications without some synchronization. That would be a welcome addition indeed > An alternative fix could be to add locking in gnutls recv and send operations internally for this specific case. That might be a good idea. IIUC once the handshake is completed, any thread can send/write, so it might not be a too broad of a change. I guess the path to be chosen is up to you :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144106888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:43:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:43:08 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: Though I have to say, from VLC's pespective, we'd prefer to be able to use false start & multiple threads. Could you confirm that false start "completion" is completely internal, and that there's no way for the calling application to know about this? Which forces us to either - Disable false start completely if using multiple threads - Always prevent send & recv to be called concurrently if false start is enabled ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144109965 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:55:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:55:12 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!927) In-Reply-To: References: Message-ID: @nmav Thank you for the response! I think we coulde just close the merge request for now, and try to add an option instead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/927#note_144113742 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Feb 22 16:55:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 22 Feb 2019 15:55:18 +0000 Subject: [gnutls-devel] GnuTLS | Changed output from stdout to stderr (!927) In-Reply-To: References: Message-ID: Merge Request !927 was closed by Ke Zhao Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/927 Project:Branches: DK_DARKmatter/gnutls:master to gnutls/gnutls:master Author: Ke Zhao Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/927 You're receiving 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 Feb 23 13:29:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 12:29:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Reassigned Merge Request 917 https://gitlab.com/gnutls/gnutls/merge_requests/917 Assignee changed to Ander Juaristi -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917 You're receiving 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 Feb 23 13:29:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 12:29:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917 You're receiving 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 Feb 23 13:32:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 12:32:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: This is almost ready. The only thing missing is to extend the password file format to recognize the non-string usernames (in hex format). I'm working on that right now. Then I would write some tests for the new feature. In the meanwhile, @nmav are you happy with the new interface introduced by this set of commits? Is there anything you would change? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917#note_144263180 You're receiving 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 Feb 23 18:45:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 17:45:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls 3.6 pseudo-randomly breaks VLC HTTP/2 (#713) In-Reply-To: References: Message-ID: > Could you confirm that false start "completion" is completely internal, and that there's no way for the calling application to know about this? Which makes us chose between either: The false start completion is internal but an application can assume that when the first recv operation is successfully completed, the handshake is also completed. I'll rename the bug to be more descriptive and add a small documentation patch to clarify the situation with false start and early start in relation with threads. We keep this open however so that we know and we can address in one of the next releases. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144291586 You're receiving 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 Feb 23 18:49:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 17:49:51 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) References: Message-ID: New Merge Request !934 https://gitlab.com/gnutls/gnutls/merge_requests/934 Project:Branches: ametzler/gnutls:tmp-ametzler-gnutls-cli-benchmark-overflow to gnutls/gnutls:master Author: Andreas Metzler Assignee: As suggested by Nikos use uint64_t instead of unsigned long to prevent type overflow on 32bit arch. #685 ## 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/934 You're receiving 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 Feb 23 19:02:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:02:53 +0000 Subject: [gnutls-devel] GnuTLS | doc: added more information on operation under multiple threads (!935) References: Message-ID: New Merge Request !935 https://gitlab.com/gnutls/gnutls/merge_requests/935 Branches: tmp-false-start-clarifications 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 clarifies the existing documentation. ## Checklist * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935 You're receiving 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 Feb 23 19:03:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:03:18 +0000 Subject: [gnutls-devel] GnuTLS | False start and early start are not multi-thread recv/send safe (#713) In-Reply-To: References: Message-ID: Please see !935 whether it clarifies the existing semantics. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144293046 You're receiving 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 Feb 23 19:27:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:27:46 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/ciphers.c: > .type = CIPHER_BLOCK, > .explicit_iv = 16, > .cipher_iv = 16}, > + { .name = "GOST28147-TC26Z-CNT", It would make sense to have unit testing of this new cipher. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295037 You're receiving 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 Feb 23 19:28:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:28:39 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/mac.c: > .id = GNUTLS_MAC_AES_CMAC_256, > .output_size = 16, > .key_size = 32}, > + {.name = "GOST28147-TC26Z-IMIT", It would make sense to have unit testing of this mac algorithm too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295074 You're receiving 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 Feb 23 19:29:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:29:42 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/cipher.c: > gost28147_set_key(ctx, key); > gost28147_set_param(ctx, &gost28147_param_CryptoPro_D); > } > + > +static void > +_gost28147_cnt_set_key_tc26z(void *ctx, const uint8_t *key) > +{ shouldn't this commit be merged with "nettle/gost: provide GOST 28147-89 CNT mode"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295136 You're receiving 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 Feb 23 19:30:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:30:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/mac.c: > set_nonce_func set_nonce; > }; > > +#if ENABLE_GOST shouldn't also this commit be merged with "nettle/gost: provide GOST 28147-89 IMIT MAC mode"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295225 You're receiving 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 Feb 23 19:33:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:33:14 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/gost/gost-wrap.c: > + */ > + > +#if HAVE_CONFIG_H > +#include "config.h" > +#endif > + > +#include > + > +#include > + > +#include > +#include "gost28147.h" > +#include > + > +void > +gost28147_kdf_cryptopro(const struct gost28147_param *param, maybe more of a general note inspired by this, is that we should consider providing a high level KDF API, as we have quite many KDF algorithms in the library. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295418 You're receiving 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 Feb 23 19:34:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:34:49 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/gost/gostdsa-vko.c: > + not, see http://www.gnu.org/licenses/. > +*/ > + > +#if HAVE_CONFIG_H > +# include "config.h" > +#endif > + > +#include > + > +#include > + > +#include "ecc-internal.h" > +#include "gostdsa.h" > + > +int > +gostdsa_vko(const struct ecc_scalar *key, Not sure if you already tried, but we should try to add it to nettle (in parallel with here) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144295514 You're receiving 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 Feb 23 19:43:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:43:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/crypto-backend.h: > gnutls_mac_output_func output; > gnutls_mac_deinit_func deinit; > gnutls_mac_fast_func fast; > + gnutls_mac_copy_func copy; That's tricky because we cannot rely for it in general. The optimized ciphers in lib/accelerated do not support it, and any registered optimizations with `gnutls_crypto_register_cipher` or `gnutls_crypto_single_cipher_register`, will not work either. In the past the `*_cipher_register` functions have prevented a lot of optimizations and make fixes like #503 hard to impossible. Maybe we should consider marking that API deprecated during 3.6.x lifetime, and make it a no-op in 3.7.0? That would allow bringing such optimizations. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144296182 You're receiving 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 Feb 23 19:44:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:44:39 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/crypto-backend.h: > /* if non-zero, the legacy value for PKCS#7 signatures will be > * written for RSA signatures. */ > unsigned int legacy; > + > + /* if non-zeri, byteswap GOST signature value (needed for TLS s/zeri/zero -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144296267 You're receiving 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 Feb 23 19:46:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:46:06 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/abstract.h: > * @GNUTLS_PRIVKEY_FLAG_EXPORT_COMPAT: Keys generated or imported as provable require an extended format which cannot be read by previous versions > * of gnutls or other applications. By setting this flag the key will be exported in a backwards compatible way, > * even if the information about the seed used will be lost. > + * @GNUTLS_PRIVKEY_SIGN_FLAG_GOST_RS_LE: Swap generated GOST 34.10 signature byte order (mainly for TLS CertificateVerify message). very ugly :( I haven't checked the details, but if that's part of the current draft, shouldn't we ask them to remove that "feature"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144296392 You're receiving 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 Feb 23 19:50:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:50:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/vko_gost.c: > +{ > + gnutls_digest_algorithm_t digalg = GNUTLS_DIG_STREEBOG_256; > + gnutls_hash_hd_t dig; > + int ret; > + > + ret = gnutls_hash_init(&dig, digalg); > + if (ret < 0) { > + gnutls_assert(); > + return ret; > + } > + > + ukm->size = gnutls_hash_get_len(digalg); > + ukm->data = gnutls_malloc(ukm->size); > + if (ukm->data == NULL) { > + gnutls_assert(); > + ret = GNUTLS_E_INTERNAL_ERROR; `GNUTLS_E_MEMORY_ERROR` is more appropriate here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144296769 You're receiving 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 Feb 23 19:53:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:53:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/vko_gost.c: > + i += len; > + > + cek.data = &data[i]; > + cek.size = ret; > + > + DECR_LEN(data_size, ret); > + > + if (data_size != 0) > + return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH); > + > + ret = calc_ukm(session, &ukm); > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + if (!privkey || privkey->type != GNUTLS_PRIVKEY_X509) { > + gnutls_assert(); no ret is set here. Apart from that, it means that one could not se gost with an HSM... that quite a limitation. Cannot we use higher level operations? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144297006 You're receiving 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 Feb 23 19:55:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 18:55:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/auth/vko_gost.c: > + ret = > + _gnutls_get_auth_info_pcert(&peer_cert, > + session->security_parameters. > + server_ctype, info); > + > + if (ret < 0) { > + gnutls_assert(); > + return ret; > + } > + > + /* just in case we are resuming a session */ > + gnutls_pk_params_release(&session->key.kshare.ecdh_params); > + > + gnutls_pk_params_init(&session->key.kshare.ecdh_params); > + > + curve = peer_cert.pubkey->params.curve; Where do we restrict this key exchange to gost curves / certs? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144297130 You're receiving 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 Feb 23 20:01:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:01:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/priority.c: > GNUTLS_GROUP_FFDHE4096, > GNUTLS_GROUP_FFDHE6144, > GNUTLS_GROUP_FFDHE8192, > +#ifdef ENABLE_GOST > + GNUTLS_GROUP_GC256A, > + GNUTLS_GROUP_GC256B, > + GNUTLS_GROUP_GC256C, Should we be enabling them by default? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144297631 You're receiving 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 Feb 23 20:03:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:03:14 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls-sig.c: > return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > > gnutls_sign_algorithm_set_client(session, sign_algo); > + pk_algo = gnutls_pubkey_get_pk_algorithm(cert->pubkey, NULL); super ugly :( -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144297728 You're receiving 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 Feb 23 20:06:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:06:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms.h: > return 0; > } > > +static inline unsigned _gnutls_kx_is_vko_gost(gnutls_kx_algorithm_t kx) may be simpler to drop `_gnutls` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144297956 You're receiving 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 Feb 23 20:13:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:13:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on src/benchmark.c: > #endif > > static void > -value2human(unsigned long bytes, double time, double *data, double *speed, > +value2human(uint64_t bytes, double time, double *data, double *speed, Please also `#include `, just in case it is not indirectly included. Else LGTM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934#note_144298371 You're receiving 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 Feb 23 20:13:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:13:22 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on src/tests.c: > #define BLOCK_CIPHERS "+3DES-CBC:+AES-128-CBC:+CAMELLIA-128-CBC:+AES-256-CBC:+CAMELLIA-256-CBC" > #define ALL_COMP "+COMP-NULL" > #define ALL_MACS "+MAC-ALL:+MD5:+SHA1" > -#define ALL_KX "+RSA:+DHE-RSA:+DHE-DSS:+ANON-DH:+ECDHE-RSA:+ECDHE-ECDSA:+ANON-ECDH" > +#define ALL_KX "+RSA:+DHE-RSA:+DHE-DSS:+ANON-DH:+ECDHE-RSA:+ECDHE-ECDSA:+ANON-ECDH:+VKO-GOST-12" shouldn't we add a specific test for GOST CS support? Otherwise it will not be clear to identify GOST only servers with the tool. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144298388 You're receiving 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 Feb 23 20:14:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:14:46 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/tls12-server-kx-neg.c: > + .server_prio = "NORMAL:-KX-ALL:+VKO-GOST-12:-VERS-ALL:+VERS-TLS1.2", > + .client_prio = "NORMAL:-KX-ALL:+VKO-GOST-12:-VERS-ALL:+VERS-TLS1.2" > + }, > + { > + .name = "TLS 1.2 VKO-GOST-12 with cred and GOST12-512 cert", > + .server_ret = 0, > + .client_ret = 0, > + .have_cert_cred = 1, > + .have_gost12_512_cert = 1, > + .not_on_fips = 1, > + .server_prio = "NORMAL:-KX-ALL:+VKO-GOST-12:-VERS-ALL:+VERS-TLS1.2", > + .client_prio = "NORMAL:-KX-ALL:+VKO-GOST-12:-VERS-ALL:+VERS-TLS1.2" > + }, > + { > + .name = "TLS 1.2 VKO-GOST-12 with cred and multiple certs", > + .server_ret = 0, What about adding TLS1.3-enabled client with GOST enabled, connecting to a TLS1.3-enabled server with GOST enabled (they should connect with TLS1.2)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144298468 You're receiving 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 Feb 23 20:16:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:16:53 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/psk-file.c: > run_test2("NORMAL:+PSK", NULL, "jas", &wrong_key, 1, 0, GNUTLS_E_FATAL_ALERT_RECEIVED, GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > run_test2("NORMAL:-KX-ALL:+PSK", NULL, "non-hex", &key, 1, 0, GNUTLS_E_FATAL_ALERT_RECEIVED, GNUTLS_E_KEYFILE_ERROR); > > - run_dhtest_ok("NORMAL:-VERS-ALL:+VERS-TLS1.3:+DHE-PSK:-GROUP-EC-ALL", "jas", &key, 0, 0); > + run_dhtest_ok("NORMAL:-VERS-ALL:+VERS-TLS1.3:+DHE-PSK:-GROUP-EC-ALL:-GROUP-GOST-ALL", "jas", &key, 0, 0); That's tricky. We shouldn't be expecting an application to switch from its pre-set priority string to a new one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144298573 You're receiving 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 Feb 23 20:25:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:25:53 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: I hope the comments were useful. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_144299097 You're receiving 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 Feb 23 20:54:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 19:54:23 +0000 Subject: [gnutls-devel] GnuTLS | Session resumption randomly fails (#706) In-Reply-To: References: Message-ID: Seeing it closely, you are right; the "Resume Handshake was completed" does not imply that the resumption occurred. That's only the ```*** This is a resumed session``` message. The reason is that we have a waiting of 50ms in `gnutls_session_get_data2` under TLS1.3 if the session tickets have not been received. That seems to be insufficient for real-world applications. A solution could be to increase the delay to 100ms or to some value calculated by the handshake roundtrips. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/706#note_144300804 You're receiving 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 Feb 23 21:05:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:05:47 +0000 Subject: [gnutls-devel] GnuTLS | Improved estimation of wait in gnutls_session_get_data2 (!936) References: Message-ID: New Merge Request !936 https://gitlab.com/gnutls/gnutls/merge_requests/936 Branches: tmp-improve-session-resumption 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 Previously we would wait an arbitrary value of 50ms for the server to send session tickets. This change makes the client wait for the estimated rount-trip time + 100 ms for the server to calculate the session tickets. This improves the chance to obtain tickets from internet servers during the call of gnutls_session_get_data2(). ## 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/936 You're receiving 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 Feb 23 21:24:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:24:16 +0000 Subject: [gnutls-devel] GnuTLS | cleanup: _gnutls_recv_handshake: added explicit sanity checks (!937) References: Message-ID: New Merge Request !937 https://gitlab.com/gnutls/gnutls/merge_requests/937 Branches: tmp-explicit-sanity-checks 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 Although, this function acts on the message provided as expected and thus it should never call a message parsing function on unexpected messages, we make a more explicit sanity check. This unifies the sanity checks existing within the involved functions. The existing test suite covers the modified paths, though the fix which is a sanity check should not be exercised by any code path. ## 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/937 You're receiving 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 Feb 23 21:24:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:24:53 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup lib/auth/cert.c as suggested by cppcheck (!924) In-Reply-To: References: Message-ID: Reassigned Merge Request 924 https://gitlab.com/gnutls/gnutls/merge_requests/924 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/924 You're receiving 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 Feb 23 21:25:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:25:19 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Reassigned Merge Request 923 https://gitlab.com/gnutls/gnutls/merge_requests/923 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923 You're receiving 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 Feb 23 21:30:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:30:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: Fix --starttls-proto=xmpp (!911) In-Reply-To: References: Message-ID: If for example I add the ftp script to run with the pop3 chat script it fails. That would be a good idea to add in the xmpp script (though in general to all), so that we verify that we are not testing something that always succeeds. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/911#note_144302909 You're receiving 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 Feb 23 21:32:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:32:36 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Reassigned Merge Request 905 https://gitlab.com/gnutls/gnutls/merge_requests/905 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/905 You're receiving 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 Feb 23 21:33:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:33:46 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Merge Request !883 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/883 Branches: tmp-fetch-fuzz-corpora-faster to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883 You're receiving 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 Feb 23 21:33:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:33:50 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Reassigned Merge Request 883 https://gitlab.com/gnutls/gnutls/merge_requests/883 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883 You're receiving 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 Feb 23 21:34:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:34:04 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) 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/883#note_144303153 You're receiving 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 Feb 23 21:36:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:36:14 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on INSTALL.md: > and gnutls-cli. > > The library depends on libnettle and gmplib. > -* gmplib: for big number arithmetic, http://gmplib.org/ > -* nettle: for cryptographic algorithms, http://www.lysator.liu.se/~nisse/nettle/ > +* gmplib: for big number arithmetic, https://gmplib.org/ > +* nettle: for cryptographic algorithms, https://www.lysator.liu.se/~nisse/nettle/ > > Optionally it may use the following libraries: > * libtasn1: For ASN.1 parsing (a copy is included, if not found), https://www.gnu.org/software/libtasn1/ > -* p11-kit: for smart card support, http://p11-glue.freedesktop.org/p11-kit.html > -* libtspi: for Trusted Platform Module (TPM) support, http://trousers.sourceforge.net/ > -* libunbound: For DNSSEC/DANE support, http://unbound.net/ > -* libz: For compression support, http://www.zlib.net/ > +* p11-kit: for smart card support, https://p11-glue.freedesktop.org/p11-kit.html This should be: https://p11-glue.github.io/p11-glue/p11-kit.html -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303270 You're receiving 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 Feb 23 21:37:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:37:09 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on README.md: > * [Texinfo](https://www.gnu.org/software/texinfo/) > * [Tar](https://www.gnu.org/software/tar/) > * [Gzip](https://www.gnu.org/software/gzip/) > -* [Texlive & epsf](http://www.tug.org/texlive/) (for PDF manual) > -* [GTK-DOC](http://www.gtk.org/gtk-doc/) (for API manual) > -* [Git](http://git-scm.com/) > -* [Perl](http://www.cpan.org/) > -* [Nettle](http://www.lysator.liu.se/~nisse/nettle/) > +* [Texlive & epsf](https://www.tug.org/texlive/) (for PDF manual) > +* [GTK-DOC](https://www.gtk.org/gtk-doc/) (for API manual) > +* [Git](https://git-scm.com/) > +* [Perl](https://www.cpan.org/) > +* [Nettle](https://www.lysator.liu.se/~nisse/nettle/) > * [Guile](https://www.gnu.org/software/guile/) > -* [p11-kit](http://p11-glue.freedesktop.org/p11-kit.html) > +* [p11-kit](https://p11-glue.freedesktop.org/p11-kit.html) same here: https://p11-glue.github.io/p11-glue/p11-kit.html -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303323 You're receiving 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 Feb 23 21:37:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:37:55 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on README.md: > * [AWK](https://www.gnu.org/software/awk/) (for make dist, pmccabe2html) > * [bison](https://www.gnu.org/software/bison) (for datetime parser in certtool) > * [libunbound](https://unbound.net/) (for DANE support) > -* [abi-compliance-checker](http://ispras.linuxbase.org/index.php/ABI_compliance_checker) (for make dist) > -* [tcsd](http://trousers.sourceforge.net/) (for TPM support; optional) > +* [abi-compliance-checker](https://ispras.linuxbase.org/index.php/ABI_compliance_checker) (for make dist) That's https://lvc.github.io/abi-compliance-checker/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303378 You're receiving 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 Feb 23 21:40:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:40:09 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/fdl-1.3.texi: > of the GNU Free Documentation License from time to time. Such new > versions will be similar in spirit to the present version, but may > differ in detail to address new problems or concerns. See > - at uref{http://www.gnu.org/copyleft/}. > + at uref{https://www.gnu.org/copyleft/}. Can we change a license? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303563 You're receiving 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 Feb 23 21:40:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:40:34 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/COPYING: > GNU General Public License for more details. > > You should have received a copy of the GNU General Public License > - along with this program. If not, see . > + along with this program. If not, see . I do not think we should change GPL -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303607 You're receiving 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 Feb 23 21:41:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 20:41:48 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/algorithms/ciphersuites.c: > * Lesser General Public License for more details. > * > * You should have received a copy of the GNU Lesser General Public License > - * along with this program. If not, see > + * along with this program. If not, see I'm not sure about this boilerplate either. Is there such a guidance for the GNU licenses? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144303665 You're receiving 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 Feb 23 23:20:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:20:22 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup lib/auth/cert.c as suggested by cppcheck (!924) In-Reply-To: References: Message-ID: Merge Request !924 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/924 Branches: tmp-cleanup-cert 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/924 You're receiving 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 Feb 23 23:21:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:21:10 +0000 Subject: [gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923) In-Reply-To: References: Message-ID: Merge Request !923 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/923 Branches: tmp-reset-after-free 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/923 You're receiving 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 Feb 23 23:22:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:22:15 +0000 Subject: [gnutls-devel] GnuTLS | Update m4/ax_code_coverage.m4 (!905) In-Reply-To: References: Message-ID: Merge Request !905 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/905 Branches: tmp-update-ax-code-coverage 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/905 You're receiving 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 Feb 23 23:22:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:22:48 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Merge Request !883 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/883 Branches: tmp-fetch-fuzz-corpora-faster 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/883 You're receiving 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 Feb 23 23:32:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:32:37 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on README.md: > * [Texinfo](https://www.gnu.org/software/texinfo/) > * [Tar](https://www.gnu.org/software/tar/) > * [Gzip](https://www.gnu.org/software/gzip/) > -* [Texlive & epsf](http://www.tug.org/texlive/) (for PDF manual) > -* [GTK-DOC](http://www.gtk.org/gtk-doc/) (for API manual) > -* [Git](http://git-scm.com/) > -* [Perl](http://www.cpan.org/) > -* [Nettle](http://www.lysator.liu.se/~nisse/nettle/) > +* [Texlive & epsf](https://www.tug.org/texlive/) (for PDF manual) > +* [GTK-DOC](https://www.gtk.org/gtk-doc/) (for API manual) > +* [Git](https://git-scm.com/) > +* [Perl](https://www.cpan.org/) > +* [Nettle](https://www.lysator.liu.se/~nisse/nettle/) > * [Guile](https://www.gnu.org/software/guile/) > -* [p11-kit](http://p11-glue.freedesktop.org/p11-kit.html) > +* [p11-kit](https://p11-glue.freedesktop.org/p11-kit.html) The is MR just changes the protocol of links, not the links itself. But I can add another commit to do that... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144309335 You're receiving 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 Feb 23 23:35:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:35:58 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on doc/fdl-1.3.texi: > of the GNU Free Documentation License from time to time. Such new > versions will be similar in spirit to the present version, but may > differ in detail to address new problems or concerns. See > - at uref{http://www.gnu.org/copyleft/}. > + at uref{https://www.gnu.org/copyleft/}. We don't change the license, just the (protocol of the) link to it. Other GNU projects already did so, e.g. check the license header of the gnulib files. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144309490 You're receiving 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 Feb 23 23:36:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:36:14 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on doc/COPYING: > GNU General Public License for more details. > > You should have received a copy of the GNU General Public License > - along with this program. If not, see . > + along with this program. If not, see . See above -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144309504 You're receiving 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 Feb 23 23:36:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 22:36:35 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/algorithms/ciphersuites.c: > * Lesser General Public License for more details. > * > * You should have received a copy of the GNU Lesser General Public License > - * along with this program. If not, see > + * along with this program. If not, see Same -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144309523 You're receiving 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 Feb 24 00:25:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 23 Feb 2019 23:25:23 +0000 Subject: [gnutls-devel] GnuTLS | False start and early start are not multi-thread recv/send safe (#713) In-Reply-To: References: Message-ID: Actually getting into the details, we may not need to protect against concurrency, at worst we may need to make `recv_state` variable atomic. I've made a proposed fix, though it would be harder to make a reproducer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144312709 You're receiving 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 Feb 24 07:29:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 06:29:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion on src/benchmark.c: > #endif > > static void > -value2human(unsigned long bytes, double time, double *data, double *speed, > +value2human(uint64_t bytes, double time, double *data, double *speed, benchmark.c has `#include "benchmark.h"` to which this patch adds `#include `. Seems strange to me to add the include to both the specific private header and the c-file. Are you sure that you want me to? (I am not trying to start a style discussion, I just wanted to doublecheck you had seen this. - If it is the right thing to do just say "Yes, I am sure." ;-) ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934#note_144339943 You're receiving 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 Feb 24 10:51:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 09:51:49 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on src/benchmark.c: > #endif > > static void > -value2human(unsigned long bytes, double time, double *data, double *speed, > +value2human(uint64_t bytes, double time, double *data, double *speed, I indeed overlooked it and I think you are talking about 'inttypes.h'. That include is more for printf format definition like `PRIu64` to printf uint64_t. 'stdint.h' is the C99 header file we need for uint64_t. Please include that and remove '__STDC_FORMAT_MACROS' (not used any more today). 'stdint.h' is also backed up by gnulib and thus very portable for us. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934#note_144350198 You're receiving 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 Feb 24 10:53:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 09:53:06 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on src/benchmark.c: > #endif > > static void > -value2human(unsigned long bytes, double time, double *data, double *speed, > +value2human(uint64_t bytes, double time, double *data, double *speed, And in this case it is enough to include 'stdint.h' just in 'benchmark.h'. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934#note_144350260 You're receiving 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 Feb 24 14:25:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 13:25:12 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) In-Reply-To: References: Message-ID: Reassigned Issue 386 https://gitlab.com/gnutls/gnutls/issues/386 Assignee changed to Ander Juaristi -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/386 You're receiving 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 Feb 24 14:26:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 13:26:03 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/386 You're receiving 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 Feb 24 14:26:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 13:26:31 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586 You're receiving 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 Feb 24 14:26:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 13:26:48 +0000 Subject: [gnutls-devel] GnuTLS | WIP: support non-NULL-terminated PSKs (!917) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/917 You're receiving 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 Feb 24 17:42:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 16:42:09 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: All discussions on Merge Request !934 were resolved by Andreas Metzler https://gitlab.com/gnutls/gnutls/merge_requests/934 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934 You're receiving 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 Feb 24 17:42:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 16:42:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion on src/benchmark.c: > #endif > > static void > -value2human(unsigned long bytes, double time, double *data, double *speed, > +value2human(uint64_t bytes, double time, double *data, double *speed, Tim R?hsen @rockdaboot wrote: > [ use stdint.h instead of inttypes.h ] Thank you, done. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934#note_144391798 You're receiving 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 Feb 24 17:50:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 16:50:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Merge Request !934 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/934 Project:Branches: ametzler/gnutls:tmp-ametzler-gnutls-cli-benchmark-overflow to gnutls/gnutls:master Author: Andreas Metzler Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934 You're receiving 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 Feb 24 17:51:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 16:51:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) 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/934#note_144392396 You're receiving 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 Feb 24 18:44:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 17:44:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: fix --benchmark-ciphers type overflow (!934) In-Reply-To: References: Message-ID: Merge Request !934 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/934 Project:Branches: ametzler/gnutls:tmp-ametzler-gnutls-cli-benchmark-overflow to gnutls/gnutls:master Author: Andreas Metzler Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/934 You're receiving 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 Feb 24 19:09:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 18:09:06 +0000 Subject: [gnutls-devel] GnuTLS | Session resumption randomly fails (#706) In-Reply-To: References: Message-ID: Reassigned Issue 706 https://gitlab.com/gnutls/gnutls/issues/706 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/706 You're receiving 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 Feb 24 19:21:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 18:21:33 +0000 Subject: [gnutls-devel] GnuTLS | False start and early start are not multi-thread recv/send safe (#713) In-Reply-To: References: Message-ID: Reassigned Issue 713 https://gitlab.com/gnutls/gnutls/issues/713 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713 You're receiving 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 Feb 24 21:31:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 20:31:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli --benchmark type overflow on 32 bit arch (#685) In-Reply-To: References: Message-ID: This was closed by !934 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/685#note_144408793 You're receiving 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 Feb 24 21:31:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 24 Feb 2019 20:31:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli --benchmark type overflow on 32 bit arch (#685) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #685: https://gitlab.com/gnutls/gnutls/issues/685 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/685 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 09:49:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 08:49:01 +0000 Subject: [gnutls-devel] GnuTLS | False start and early start are not multi-thread recv/send safe (#713) In-Reply-To: References: Message-ID: Really cool. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/713#note_144534968 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 09:49:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 08:49:12 +0000 Subject: [gnutls-devel] GnuTLS | Make false start and early start multi-thread recv/send safe (3df3c03b) In-Reply-To: References: Message-ID: Nice for the prompt fix! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/3df3c03b047477565f15852ac51c534730b6f6ec#note_144535048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:09:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:09:05 +0000 Subject: [gnutls-devel] GnuTLS | cleanup: _gnutls_recv_handshake: added explicit sanity checks (!937) In-Reply-To: References: Message-ID: Aren't there any other packet types that are client|server only ? GNUTLS_HANDSHAKE_SERVER_HELLO_DONE, ... ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/937#note_144542608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:24:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:24:40 +0000 Subject: [gnutls-devel] GnuTLS | fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Merge Request !935 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/935 Branches: tmp-false-start-clarifications to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:24:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:24:58 +0000 Subject: [gnutls-devel] GnuTLS | fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Reassigned Merge Request 935 https://gitlab.com/gnutls/gnutls/merge_requests/935 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:25:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:25:53 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) In-Reply-To: References: Message-ID: @nmav ping -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928#note_144550366 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:33:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:33:10 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on INSTALL.md: > and gnutls-cli. > > The library depends on libnettle and gmplib. > -* gmplib: for big number arithmetic, http://gmplib.org/ > -* nettle: for cryptographic algorithms, http://www.lysator.liu.se/~nisse/nettle/ > +* gmplib: for big number arithmetic, https://gmplib.org/ > +* nettle: for cryptographic algorithms, https://www.lysator.liu.se/~nisse/nettle/ > > Optionally it may use the following libraries: > * libtasn1: For ASN.1 parsing (a copy is included, if not found), https://www.gnu.org/software/libtasn1/ > -* p11-kit: for smart card support, http://p11-glue.freedesktop.org/p11-kit.html > -* libtspi: for Trusted Platform Module (TPM) support, http://trousers.sourceforge.net/ > -* libunbound: For DNSSEC/DANE support, http://unbound.net/ > -* libz: For compression support, http://www.zlib.net/ > +* p11-kit: for smart card support, https://p11-glue.freedesktop.org/p11-kit.html Commit to fix the p11-kit URLs has been added. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144553914 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:37:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:37:19 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: All discussions on Merge Request !910 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/910 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 10:37:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 09:37:20 +0000 Subject: [gnutls-devel] GnuTLS | Change HTTP:// references to HTTPs:// (generally) (!910) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on README.md: > * [AWK](https://www.gnu.org/software/awk/) (for make dist, pmccabe2html) > * [bison](https://www.gnu.org/software/bison) (for datetime parser in certtool) > * [libunbound](https://unbound.net/) (for DANE support) > -* [abi-compliance-checker](http://ispras.linuxbase.org/index.php/ABI_compliance_checker) (for make dist) > -* [tcsd](http://trousers.sourceforge.net/) (for TPM support; optional) > +* [abi-compliance-checker](https://ispras.linuxbase.org/index.php/ABI_compliance_checker) (for make dist) Commit pushed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/910#note_144555416 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 12:43:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 11:43:33 +0000 Subject: [gnutls-devel] GnuTLS | fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Thanks a lot for the quick fix! This seems to fix the observable issue from #713, however the race is still present, as the accesses to `session->internals.recv_state` are not atomic ``` WARNING: ThreadSanitizer: data race (pid=19622) Read of size 4 at 0x7b8c00012014 by thread T11: #0 gnutls_record_send2 /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1982 (libgnutls_plugin.so+0x20c52) #1 gnutls_record_send /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1943 (libgnutls_plugin.so+0x2111f) #2 gnutls_Send ../../modules/misc/gnutls.c:175 (libgnutls_plugin.so+0x197f3) #3 vlc_https_send ../../modules/access/http/h2output.c:204 (libhttps_plugin.so+0xfddd) #4 vlc_h2_frame_send ../../modules/access/http/h2output.c:250 (libhttps_plugin.so+0xffdc) #5 vlc_h2_output_thread ../../modules/access/http/h2output.c:265 (libhttps_plugin.so+0x1006d) #6 vlc_h2_client_output_thread ../../modules/access/http/h2output.c:299 (libhttps_plugin.so+0x101fb) #7 (libtsan.so.0+0x29b4d) Previous write of size 4 at 0x7b8c00012014 by thread T12: #0 check_session_status /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1689 (libgnutls_plugin.so+0x20204) #1 _gnutls_recv_int /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:1752 (libgnutls_plugin.so+0x2055c) #2 gnutls_record_recv /home/chouquette/dev/vlc/contrib/native/gnutls/lib/record.c:2262 (libgnutls_plugin.so+0x215d4) #3 gnutls_Recv ../../modules/misc/gnutls.c:146 (libgnutls_plugin.so+0x196d0) #4 vlc_https_recv ../../modules/access/http/h2conn.c:563 (libhttps_plugin.so+0x122c4) #5 vlc_h2_frame_recv ../../modules/access/http/h2conn.c:606 (libhttps_plugin.so+0x12453) #6 vlc_h2_recv_thread ../../modules/access/http/h2conn.c:656 (libhttps_plugin.so+0x1270d) #7 (libtsan.so.0+0x29b4d) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144608641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 13:11:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 12:11:27 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Thank you. This race should not be an issue in any CPUs, but yes, we should use an atomic type there. Marked it as WIP until this is done. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144620131 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 13:16:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 12:16:58 +0000 Subject: [gnutls-devel] GnuTLS | cleanup: _gnutls_recv_handshake: added explicit sanity checks (!937) In-Reply-To: References: Message-ID: I put the checks only to places where a complex function is called which may have side-effects to session state. The server hello done had no side effect so I didn't change it. Maybe these checks qualify more for an `assert()` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/937#note_144621930 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 13:22:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 12:22:38 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Not sure if atomic is enough. It just makes a read-modify-write atomic. E.g. it doesn't help if one thread reads the variable several times and another thread modifies it at the same time. Modern compiler optimization helps a lot (reading just once and keeping the value in a register), but you can't rely on it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144623722 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 13:38:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 12:38:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: I agree that an atomic variable would not fix the issue properly, but having a temporary variable sounds like it might trigger some Time-Of-Check-Time-To-Use types bugs, which might be harder to debug. I don't think there's a way around having a mutex here is you need to check a flag and do some processing depending on the value of that flag, especially if that means updating some states afterward. That being said, maybe this commit is fine for the time being, as it indeed fixes the observable issue. Another follow up issue could be spawned of out it -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144628872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 13:42:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 12:42:47 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: What I think we should address is the problem of a transition from A->B, is read either as A or B. A tmp variable as I understand it may not help in the case where the platform does not guarrantee atomicity in writes. That's why I think atomic will solve it. The transitions we care to protect from (RECV_STATE_FALSE_START_HANDLING, RECV_STATE_FALSE_START, and RECV_STATE_0) do not require us to use locks (i.e doesn't matter if we read HANDLING while we are in FALSE_START). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144630438 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 14:59:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 13:59:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: As you already said, on all supported platform the read and write to/from int already is atomic. Making the variable atomic just helps unsupported platforms (e.g. 16 bit data bus). What I think of is code like ``` if (session->internals.recv_state != RECV_STATE_FALSE_START && session->internals.recv_state != RECV_STATE_FALSE_START_HANDLING && session->internals.recv_state != RECV_STATE_EARLY_START && session->internals.recv_state != RECV_STATE_EARLY_START_HANDLING && !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) ... ``` If a non-optimizing compiler reads the variable 4x, this allows a second thread to change the value between two comparisons. It might be unlikely, but to be sure you would save `session->internals.recv_state` into a temp variable and use that for comparison. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144663146 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 15:13:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 14:13:47 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Ok, makes sense. I've added thread sanitizer runs which uncovered few more issues. Introduced fixes for them, but I'd appreciate a second pair of eyes as they were quickly done. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144670379 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 15:17:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 14:17:58 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Tim R?hsen started a new discussion on lib/constate.c: > record_parameters_st **params; > int ret; > > + GNUTLS_STATIC_MUTEX_LOCK(epoch_lock); You simplify the code (is a matter of favor): ``` GNUTLS_STATIC_MUTEX_LOCK(epoch_lock); ret = epoch_resolve(session, epoch_rel, &epoch); params = epoch_get_slot(session, epoch); GNUTLS_STATIC_MUTEX_UNLOCK(epoch_lock); /* do diagnostics here */ ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144672340 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 15:19:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 14:19:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: But in case you have 2 threads sending/receiving during `RECV_STATE_FALSE_START_HANDLING` or `RECV_STATE_EARLY_START_HANDLING`, don't you need to block the 2nd thread until the handling is completed? It feels to me like if you don't, you might have 2 threads trying to process the handshake during recv/send -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144674292 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 15:23:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 14:23:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen started a new discussion on lib/handshake-tls13.c: > > > /* explicitly reset any false start flags */ > - session->internals.recv_state = RECV_STATE_0; > session->internals.initial_negotiation_completed = 1; > + session->internals.recv_state = RECV_STATE_0; Is there any reason for this reordering? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144680378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 15:25:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 14:25:47 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen started a new discussion on lib/record.c: > * data. We allow sending however, if we are in false start handshake > * state. */ > if (session->internals.recv_state != RECV_STATE_FALSE_START && > + session->internals.recv_state != RECV_STATE_FALSE_START_HANDLING && > session->internals.recv_state != RECV_STATE_EARLY_START && > - !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) > - return gnutls_assert_val(GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE); > + session->internals.recv_state != RECV_STATE_EARLY_START_HANDLING && > + !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) { > + /* this additional check is to avoid a mutex for applications sending > + * and receiving in parallel. */ > + if (!session->internals.initial_negotiation_completed) Strictly speaking, you can't have a check on a non-atomic variable/non locked context if the variable was potentially modified by another thread. Here, your compiler is completely free to remove it if it can prove that this check isn't relevant in a monothread context. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144682392 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 16:33:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 15:33:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/record.c: > * data. We allow sending however, if we are in false start handshake > * state. */ > if (session->internals.recv_state != RECV_STATE_FALSE_START && > + session->internals.recv_state != RECV_STATE_FALSE_START_HANDLING && > session->internals.recv_state != RECV_STATE_EARLY_START && > - !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) > - return gnutls_assert_val(GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE); > + session->internals.recv_state != RECV_STATE_EARLY_START_HANDLING && > + !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) { > + /* this additional check is to avoid a mutex for applications sending > + * and receiving in parallel. */ > + if (!session->internals.initial_negotiation_completed) I find it ugly too. Do you have some suggestion here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144758717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 16:34:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 15:34:20 +0000 Subject: [gnutls-devel] GnuTLS | "certificate_required" alert is unknown (#715) References: Message-ID: New Issue was created. Issue 715: https://gitlab.com/gnutls/gnutls/issues/715 Author: Daiki Ueno Assignee: ## Description of problem: The server utilizing post-handshake authentication may send a "certificate_required" alert (116) when the client doesn't send any certificate. GnuTLS doesn't know that alert currently. ## Version of gnutls used: gnutls-3.6.6-1.fc29.x86_64 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora ## How reproducible: Steps to Reproduce: * set up apache with post-handshake authentication enabled ``` Alias /aaa/ /var/www/aaa/ SSLOptions +StrictRequire SSLRequireSSL SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +FakeBasicAuth ``` * connect to the server with gnutls-cli: ``` { printf 'GET /aaa HTTP/1.1\r\nHost: localhost.localdomain\r\n\r\n'; sleep 10; } | gnutls-cli --x509cafile=Documents/data/ca-cert.pem --post-handshake-auth -d 6 -p 443 localhost.localdomain ``` ## Actual results: ``` *** Re-auth was performed. |<5>| REC[0x5586e0e86ae0]: SSL 3.3 Application Data packet received. Epoch 2, length: 19 |<5>| REC[0x5586e0e86ae0]: Expected Packet Application Data(23) |<5>| REC[0x5586e0e86ae0]: Received Packet Application Data(23) with length: 19 |<5>| REC[0x5586e0e86ae0]: Decrypted Packet[3] Alert(21) with length: 2 |<5>| REC[0x5586e0e86ae0]: Alert[2|116] - (null) - was received |<3>| ASSERT: record.c[record_add_to_buffers]:877 |<3>| ASSERT: record.c[record_add_to_buffers]:884 |<3>| ASSERT: record.c[_gnutls_recv_in_buffers]:1567 |<3>| ASSERT: record.c[_gnutls_recv_int]:1766 *** Fatal error: A TLS fatal alert has been received. *** Received alert [116]: (unknown) *** Server has terminated the connection abnormally. ``` ## Expected results: 116 should be replaced with readable description. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/715 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 16:35:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 15:35:51 +0000 Subject: [gnutls-devel] GnuTLS | "certificate_required" alert is unknown (#715) In-Reply-To: References: Message-ID: It might be a bit tricky to write a test: either sending the alert in gnutls-serv or using tls.py to emulate the mod_ssl behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/715#note_144761390 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 16:36:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 15:36:10 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: > But in case you have 2 threads sending/receiving during `RECV_STATE_FALSE_START_HANDLING` or `RECV_STATE_EARLY_START_HANDLING`, don't you need to block the 2nd thread until the handling is completed? It feels to me like if you don't, you might have 2 threads trying to process the handshake during recv/send Sending is ok in the `RECV_STATE_FALSE_START_HANDLING` or the early variant. The only need that sending needs to know is the actual state of the handshake, and if the state is incomplete, to check whether we are doing false/early start (and if not error out). Receiving is of course not ok, but that cannot be, unless the application is receiving in parallel in two threads (which is not supported). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144761557 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 17:31:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 16:31:18 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Just to be sure, you mean that two threads sending at the same time is not supported, not sending & receiving from 2 different threads. In which case that should work for us, the creation of receiver/sender threads should act as the required memory barrier (since we spawn the threads after the `gnutls_handshake` call returns); at least as far as the `recv_state` variable is concerned; but then I'm not sure this would work for `initial_negotiation_completed` since it would be modified by the thread completing the handshake at a later time right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144810593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 17:50:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 16:50:38 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/record.c: > * data. We allow sending however, if we are in false start handshake > * state. */ > if (session->internals.recv_state != RECV_STATE_FALSE_START && > + session->internals.recv_state != RECV_STATE_FALSE_START_HANDLING && > session->internals.recv_state != RECV_STATE_EARLY_START && > - !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) > - return gnutls_assert_val(GNUTLS_E_UNAVAILABLE_DURING_HANDSHAKE); > + session->internals.recv_state != RECV_STATE_EARLY_START_HANDLING && > + !(session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT)) { > + /* this additional check is to avoid a mutex for applications sending > + * and receiving in parallel. */ > + if (!session->internals.initial_negotiation_completed) If you can get away with waiting for the negotiation to complete, maybe an atomic variable for the `initial_negotiation_completed` flag & a semaphore to delay a call to recv while send is completing the handshake, or the other way around? If the values of `recv_state` & `initial_negotiation_completed` are dependent on each other, I'm not sure you can go away without a mutex though. If `recv_state` doesn't change after the initial call to `gnutls_handshake` then the checks above will work fine. AFAICS `initial_negotiation_completed` will be updated from a subsequent call to recv/send, so you need to synchronize read/writes to it. If that value doesn't need to be updated based on recv_state, an atomic variable is enough, but it seems the sequence goes something like this: ``` recv_handshake_final() { switch ( final_state ) { //..... case STATE31: _gnutls_recv_finished() // initial_negotiation_completed = 1; final_state = STATE0; } } ``` That kind of logic requires a lock IMO. Having `final_state` equal to `STATE31` at the begining of the switch doesn't mean it will still be equal to `STATE31` by the time `_gnutls_recv_finished` returns. The way I see it you need a lock to ensure that 2 racing threads would not perform the same steps simultaneously. That being said, I do not know the GnuTLS sources enough (let alone TLS itself), and I might be completely missing the point, misunderstanding the call graph, [...], so please forgive me if some comments are completely out of touch with reality -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144817381 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 19:10:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 18:10:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: > Just to be sure, you mean that two threads sending at the same time is not supported, not sending & receiving from 2 different threads. right > In which case that should work for us, the creation of receiver/sender threads should act as the required memory barrier (since we spawn the threads after the `gnutls_handshake` call returns); at least as far as the `recv_state` variable is concerned; but then I'm not sure this would work for `initial_negotiation_completed` since it would be modified by the thread completing the handshake at a later time right? yes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144842518 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Feb 25 19:30:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 25 Feb 2019 18:30:37 +0000 Subject: [gnutls-devel] GnuTLS | WIP: fixed operation under multiple threads (!935) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c: > record_parameters_st **params; > int ret; > > + GNUTLS_STATIC_MUTEX_LOCK(epoch_lock); Thanks. Simplified, based on this but a little different -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/935#note_144847166 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 09:35:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 08:35:47 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for CNT_IMIT TLS 1.2 GOST cipher suite (!920) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tls-sig.c: > return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > > gnutls_sign_algorithm_set_client(session, sign_algo); > + pk_algo = gnutls_pubkey_get_pk_algorithm(cert->pubkey, NULL); Note that I do not refer to the code, but to the concept. If changing the spec is not possible, maybe we can improve the concept by making the le change part of the signature algorithm property? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/920#note_145002757 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 10:42:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 09:42:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: The missing HMAC file for libgmp is now installed in Fedora after applying this update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1cfd03ca89 I verified that the build image for Fedora 29 has been already updated, so there is no more blockers for this PR. I changed the previous approach of adding a whole new build to run with the integrity checks enabled and enabled the integrity checks in the existing FIPS140-2 build instead. I also added a line in the build script to generate the HMAC files for the fresh compiled libgnutls so that the integrity tests can be performed. I'll remove the WIP status from this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_145027969 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:24:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:24:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: It seems that the new cppcheck catches an issue in some code from nettle. I added a suppression for the style hint in master -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_145170597 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:25:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:25:30 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: Merge Request !873 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/873 Project:Branches: ansasaki/gnutls:fix_fips_lib_name to gnutls/gnutls:master Author: Anderson Sasaki Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:26:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:26:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: LGTM, thank you for driving this! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_145171600 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:26:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:26:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: Reassigned Merge Request 873 https://gitlab.com/gnutls/gnutls/merge_requests/873 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:26:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:26:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:33:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:33:22 +0000 Subject: [gnutls-devel] GnuTLS | "certificate_required" alert is unknown (#715) In-Reply-To: References: Message-ID: What do you think to test? If you care about gnutls recognizing this alert, then maybe adding this in `tests/alerts.c` may be the easiest (a test which sends two alerts under TLS1.2). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/715#note_145174825 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:38:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:38:55 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: Reassigned Issue 676 https://gitlab.com/gnutls/gnutls/issues/676 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:39:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:39:18 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #676: https://gitlab.com/gnutls/gnutls/issues/676 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:39:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:39:17 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: This was addressed by !879 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_145178077 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:43:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14:43:27 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: clarify GNUTLS_PKCS11_TOKEN_MODNAME presence [ci skip] (!938) References: Message-ID: New Merge Request !938 https://gitlab.com/gnutls/gnutls/merge_requests/938 Branches: tmp-token-modname-clarifications 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 clarifies the presence of the GNUTLS_PKCS11_TOKEN_MODNAME value. ## Checklist * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/938 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 15:53:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 14: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: Reassigned Issue 633 https://gitlab.com/gnutls/gnutls/issues/633 Assignee changed to Nikos Mavrogiannopoulos -- 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 Tue Feb 26 16:13:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 15:13:28 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) References: Message-ID: New Merge Request !939 https://gitlab.com/gnutls/gnutls/merge_requests/939 Project:Branches: cryptomilk/gnutls:master-aes-ccm to gnutls/gnutls:master Author: Andreas Schneider Assignee: It took me two days to figure out how to use that AEAD API as the documentation is not very useful. It took me than one day to figure out that the nonce size returned by gnutls_cipher_get_iv_size() is one byte to big, looks like every one uses 11 bytes, for example https://tools.ietf.org/html/rfc4309 And the same with Microsoft Windows, they use L=4. I think 11 is more correct, however this should be documented that the returned size for some ciphers might not be the one you need! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 16:18:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 15:18:33 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) References: Message-ID: New Issue was created. Issue 716: https://gitlab.com/gnutls/gnutls/issues/716 Author: Andreas Schneider Assignee: The documentation is only very basic. There are a lot of thing which are totally unclear. One example is e.g. for the gnutls_aead_cipher_encryptv() function. Can you just set a auth_iov with count 1 or does it need to be the same count as iov? The ctext only says 'the encrypted data', it doesn't mention that at the end of the cipher text the tag get appended. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 16:21:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 15:21:29 +0000 Subject: [gnutls-devel] GnuTLS | Document that the returned size by gnutls_cipher_get_iv_size() might not be the correct size for the nonce (#717) References: Message-ID: New Issue was created. Issue 717: https://gitlab.com/gnutls/gnutls/issues/717 Author: Andreas Schneider Assignee: In case of AES-CCM 12 is returned, which is in most cases wrong. The RFC states: 2. A nonce N of 15-L octets. Within the scope of any encryption key K, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties of this mode. Valid values of L range between 2 octets and 8 octets (the value L=1 is reserved). So the documentation of the function should tell the user to check the RFC and implementation if the size is fixed or needs to be calculated differently! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 16:32:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 15:32:41 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_encryptv2() (#718) References: Message-ID: New Issue was created. Issue 718: https://gitlab.com/gnutls/gnutls/issues/718 Author: Andreas Schneider Assignee: Please implement: ``` int gnutls_aead_cipher_encryptv(gnutls_aead_cipher_hd_t handle, const void *nonce, size_t nonce_len, const giovec_t * auth_iov, int auth_iovcnt, const giovec_t *iov, int iovcnt, void *tag, size_t *tag_size); ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/718 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 16:33:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 15:33:46 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) References: Message-ID: New Issue was created. Issue 719: https://gitlab.com/gnutls/gnutls/issues/719 Author: Andreas Schneider Assignee: Please also implement gnutls_aead_cipher_decryptv(). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 18:45:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 17:45:08 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_encryptv2() (#718) In-Reply-To: References: Message-ID: Or name it `gnutls_aead_cipher_encrypt_iov()` and `gnutls_aead_cipher_decrypt_iov()` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/718#note_145255892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Feb 26 19:22:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 18:22:51 +0000 Subject: [gnutls-devel] GnuTLS | Use ChangeLog date instead of build date (!928) In-Reply-To: References: Message-ID: >> It is also worth nothing that a "Copyright 2019" will remain correct even in future years. > IMO that is true as long as the effected source isn't changed. And the only place we use @year@ as substitution variable is `src/args-std.def.in`. Whenever someone runs `./configure` or `./config.status`, this file is processed and the copyright year in `src/args-std.def` becomes updated. This also seems wrong to me. We should only update the year if the source code changes - a not 100% but much better approach would be to *only* take the year of the last git commit. We could generate that within bootstrap.conf which is not part of a tarball build. @nmav WDYT ? It makes sense to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/928#note_145264928 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 00:33:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 26 Feb 2019 23:33:23 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) References: Message-ID: New Merge Request !940 https://gitlab.com/gnutls/gnutls/merge_requests/940 Project:Branches: DK_DARKmatter/gnutls:master to gnutls/gnutls:master Author: Ke Zhao Assignee: In some cases, we may not want to print all the information from client to stdout. With this option, program will create a temporary txt log file on your current path, and redirect some imformation to that file. The response from the server will not be changed, you can still observe the response directly at the client. ## 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/940 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:30:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:30:38 +0000 Subject: [gnutls-devel] GnuTLS | Improve documentation for gnutls_cipher_get_iv_size (!941) References: Message-ID: New Merge Request !941 https://gitlab.com/gnutls/gnutls/merge_requests/941 Branches: tmp-doc-update-iv 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 clarifies what is returned and what is to be expected on algorithms with variable IV sizes. ## Checklist * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/941 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:30:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:30:58 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:30:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:30:59 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) In-Reply-To: References: Message-ID: Reassigned Merge Request 939 https://gitlab.com/gnutls/gnutls/merge_requests/939 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:31:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:31:28 +0000 Subject: [gnutls-devel] GnuTLS | Document that the returned size by gnutls_cipher_get_iv_size() might not be the correct size for the nonce (#717) In-Reply-To: References: Message-ID: Thank you for that. I have opened !941 to clarify that message. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/717#note_145445483 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:31:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:31:32 +0000 Subject: [gnutls-devel] GnuTLS | Document that the returned size by gnutls_cipher_get_iv_size() might not be the correct size for the nonce (#717) In-Reply-To: References: Message-ID: Reassigned Issue 717 https://gitlab.com/gnutls/gnutls/issues/717 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:31:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:31:34 +0000 Subject: [gnutls-devel] GnuTLS | Document that the returned size by gnutls_cipher_get_iv_size() might not be the correct size for the nonce (#717) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.7 (Jan 26, 2019?Mar 27, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/19 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:32:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:32:15 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) In-Reply-To: References: Message-ID: Please see !941 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939#note_145445927 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:34:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:34:43 +0000 Subject: [gnutls-devel] GnuTLS | Improve documentation for gnutls_cipher_get_iv_size (!941) In-Reply-To: References: Message-ID: I would give some examples: For algorithms with variable size IV (e.g AES-CCM, FOO, BAR), the returned size will be the one used by TLS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/941#note_145446704 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:35:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:35:51 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) In-Reply-To: References: Message-ID: Yes, I think with improved documentation it is fine. Closing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939#note_145447081 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:35:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:35:51 +0000 Subject: [gnutls-devel] GnuTLS | lib: Set the AES 128 CCM iv size to 11 (!939) In-Reply-To: References: Message-ID: Merge Request !939 was closed by Andreas Schneider Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/939 Project:Branches: cryptomilk/gnutls:master-aes-ccm to gnutls/gnutls:master Author: Andreas Schneider Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:41:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:41:24 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: Hi, Thank you for that. Would you like to propose some changes that will make the message more clear, or more detailed description of what you miss? It is on the man-pages or [in the manual](https://gnutls.org/manual/gnutls.html#Symmetric-algorithms)? More specifically: > Can you just set a auth_iov with count 1 or does it need to be the same count as iov? Do you mean have an `auth_iovcnt` != `iovcnt`? The answer is of course, but it would help me to understand what made you think that you could not. > The ctext only says 'the encrypted data', it doesn't mention that at the end of the cipher text the tag get appended. In the AEAD ciphers, the encrypted data include the tag. In some algorithms like CCM, GCM the tag is appended to the "normally" encrypted data. In some other algorithms the tag is part of the IV (i.e., prepended to data). There is no separation of ciphertext, and tag. The [AEAD rfc](https://tools.ietf.org/html/rfc5116#section-2.1) is quite clear on that: ``` The authenticated encryption operation has four inputs, each of which is an octet string: .. . .. There is a single output: A ciphertext C, ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145449016 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:43:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:43:59 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: gnutls_aead_cipher_decrypt() should mention that the tag needs to be appended to the ctext and the tag_size will define the size of it. It should be better explained that the tag will be verified by the decrypt function. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145450131 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:45:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:45:22 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) In-Reply-To: References: Message-ID: What is the use-case you have in mind? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719#note_145450633 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:46:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:46:13 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: As you pass an auth_iov someone could assume that it needs to be the same as the iov_count. Something like: The auth_iov_count can be smaller than the iov_count then the last auth_iov buffer will be reused. If that is the case ... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145450898 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:48:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:48:15 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) In-Reply-To: References: Message-ID: See: * libcli:smb: Use GnuTLS AES in smb2_signing_decrypt_pdu() in https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-gnutls I have to memcpy everything to a buffer to pass it in and memcpy it back. encryptv is a bit better, but only available in 3.6 so I have to do the same for encrypt. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719#note_145451645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 09:56:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 08:56:10 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) In-Reply-To: References: Message-ID: Oh, I just found out, I can't use a stack variable I need to allocate it because transfering large files it gets 8MB big. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719#note_145454605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 10:02:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 09:02:42 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: > gnutls_aead_cipher_decrypt() should mention that the tag needs to be appended to the ctext and the tag_size will define the size of it. That's tricky. As I said not all AEAD ciphers append the authentication tag in the end of the ciphertext. I've made some clarifications in !941 ; I'd appreciate if you could check them, and propose some update if they are not enough. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145457034 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 10:03:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 09:03:44 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: > As you pass an auth_iov someone could assume that it needs to be the same as the iov_count. > Something like: The auth_iov_count can be smaller than the iov_count then the last auth_iov buffer will be reused. I am not sure I understand that text. Just to clarify the auth_iov, and iov are unrelated buffers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145457537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 10:07:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 09:07:20 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) In-Reply-To: References: Message-ID: So is it that the smb protocol does not transfer the encrypted data in sequence? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719#note_145458982 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 10:47:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 09:47:39 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_decryptv() (#719) In-Reply-To: References: Message-ID: No, it doesn't. The tag is part of the header (protocol id, signature, nonce, ..), then comes the encrypted data. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/719#note_145474994 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 10:51:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 09:51:12 +0000 Subject: [gnutls-devel] GnuTLS | Implement gnutls_aead_cipher_encryptv2() (#718) In-Reply-To: References: Message-ID: We get a header with protocol id, signature, nonce, etc. then comes the encrypted data. Currently I have to memcpy the encrypted data back into the iov. I would like to have inplace decryption. The tag (signature) is part of the header, so it is not in the iov, however it could also be put in the iov as the last element, if you prefer that. Also the memory I have to allocate exceeds the allowed stack size, so with that API I would avoid not only the memcpy but also allocations. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/718#note_145476377 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 11:07:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 10:07:36 +0000 Subject: [gnutls-devel] GnuTLS | Improve the gnutls_aead_cipher documentation (#716) In-Reply-To: References: Message-ID: 9c91b329 looks much better. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/716#note_145487056 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 13:41:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 12:41:42 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: clarify GNUTLS_PKCS11_TOKEN_MODNAME presence [ci skip] (!938) In-Reply-To: References: Message-ID: Merge Request !938 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/938 Branches: tmp-token-modname-clarifications to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/938 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 14:59:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 13:59:04 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) In-Reply-To: References: Message-ID: @nmav Hi Nikos, this time I just add an option for the client, it should has no interference with current code. Please tell me if there is anything I need to imrpove. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/940#note_145576013 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 16:31:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 15:31:07 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: I have resolved my issue with the examples from @vcunat. I want to thank to all of you for the showed interest. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_145614212 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 16:31:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 15:31:08 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: Issue was closed by Ludio Issue #673: https://gitlab.com/gnutls/gnutls/issues/673 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 19:34:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 18:34:13 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) In-Reply-To: References: Message-ID: @DK\_DARKmatter We definitely don't want a hard-coded file name. We want the user to specify the file name. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/940#note_145686504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 19:40:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 18:40:13 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) In-Reply-To: References: Message-ID: @npmccallum I see. I will improve it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/940#note_145687746 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Feb 27 19:46:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 27 Feb 2019 18:46:23 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/940 was reviewed by Nathaniel McCallum -- Nathaniel McCallum started a new discussion on src/cli.c: > + dup2(oldstdout,STDOUT_FILENO); > + close(oldstdout); > + } This `do_once` semantic is unnecessary if you refactor the code as I stated above. Just set the global variable to `NULL` after fclose(). -- Nathaniel McCallum started a new discussion on src/cli.c: > + oldstdout=dup(STDOUT_FILENO); > + dup2(log_file,STDOUT_FILENO); > + close(log_file); This is definitely the wrong approach. Replacing STDOUT, while clever, is going to lead to very bad behavior by the application. You need to use `fopen()` and create a global `FILE` instance, which defaults to `stdout` (the existing behavior). All logging commands then need to be updated to use this new global variable. The patch should be MUCH larger than this. -- Nathaniel McCallum started a new discussion on src/cli.c: > + log_file = open("stdout_log.txt",O_WRONLY | O_CREAT); > + if(log_file <=0){ > + fprintf(stderr,"Failed to create a log file!\n The Errno is %m"); Like above, follow the style. Also, your error message needs to be changed. You don't always want to create a file. -- Nathaniel McCallum started a new discussion on src/cli.c: > } > - > + if(HAVE_OPT(FILE_LOG)){ Space after `if`. Space before `{`. You need to make sure you match the existing code style and not impose your own. -- Nathaniel McCallum started a new discussion on src/cli.c: > - > + if(HAVE_OPT(FILE_LOG)){ > + log_file = open("stdout_log.txt",O_WRONLY | O_CREAT); We definitely don't want a hard-coded file name. The option should specify the file name. That way we can redirect to files like `/dev/null` or `/dev/stdout`. Also, I'm pretty sure you want `fopen()` here, not `open()`. -- Nathaniel McCallum started a new discussion on src/cli.c: > int ret; > int ii, inp; > + int oldstdout = -1,log_file = -1,do_once=0; @DK\_DARKmatter Almost every code style (except really weird ones) specify a space after a comma. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/940 You're receiving 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 Feb 28 08:55:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 07:55:41 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PKCS11_TOKEN_MODNAME is unavailable when a provider is manually loaded (#633) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #633: https://gitlab.com/gnutls/gnutls/issues/633 -- 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 Feb 28 08:55:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 07:55:41 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11: clarify GNUTLS_PKCS11_TOKEN_MODNAME presence [ci skip] (!938) In-Reply-To: References: Message-ID: Merge Request !938 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/938 Branches: tmp-token-modname-clarifications to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/938 You're receiving 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 Feb 28 09:55:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 08:55:40 +0000 Subject: [gnutls-devel] GnuTLS | LGTM.com integration (#602) In-Reply-To: References: Message-ID: @nmav I need owner/admin status to enable MR analysis at LGTM. Once enabled, I would add a MR with a `.lgtm.yml` file. They have an automatic dependency detection - which sometimes fails. So there may be some iterations until it's perfect. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/602#note_145837826 You're receiving 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 Feb 28 11:52:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 10:52:44 +0000 Subject: [gnutls-devel] GnuTLS | LGTM.com integration (#602) In-Reply-To: References: Message-ID: I've given you owner access. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/602#note_145911925 You're receiving 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 Feb 28 12:12:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 11:12:34 +0000 Subject: [gnutls-devel] GnuTLS | LGTM.com integration (#602) In-Reply-To: References: Message-ID: Thx, just asked LGTM to include GnuTLS from Gitlab (Gitlab projects have to be manual added by them, not sure why they don't fix that). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/602#note_145919197 You're receiving 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 Feb 28 17:10:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 28 Feb 2019 16:10:19 +0000 Subject: [gnutls-devel] GnuTLS | Add an option "--file-log" to redirect some information to a temporary file (!940) In-Reply-To: References: Message-ID: @nmav Hi Nikos, Can I add an shortcut like -f to represent my new option? Because I think this may cause trouble when you are going to add new features in the future. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/940#note_146047952 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: