From gnutls-devel at lists.gnutls.org Tue Jan 1 12:22:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 11:22:35 +0000 Subject: [gnutls-devel] GnuTLS | ex-client-x509 3.6.5 cannot connect to gnutls-serv (#663) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #663: https://gitlab.com/gnutls/gnutls/issues/663 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/663 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 12:22:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 11:22:35 +0000 Subject: [gnutls-devel] GnuTLS | examples: use a valid DNS name (!848) In-Reply-To: References: Message-ID: Merge Request !848 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/848 Branches: tmp-fix-examples to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/848 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 12:24:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 11:24:45 +0000 Subject: [gnutls-devel] GnuTLS | cipher-test-api fails 3des-cbc test when nettle is built in release mode (#665) In-Reply-To: References: Message-ID: Would be nice to send it to nettle. Note that the best is to send your patches in the `nettle-bugs` mailing list as this project doesn't accept PRs yet. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/665#note_128230560 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 13:31:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 12:31:03 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: [This](https://github.com/curl/curl/pull/1336) seems to be related. What is your version of MacOS/OSX ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662#note_128232887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 14:42:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 13:42:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in doc/ (!849) References: Message-ID: New Merge Request !849 https://gitlab.com/gnutls/gnutls/merge_requests/849 Branches: tmp-fix-typos-in-doc 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 Fix some typos ## 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/849 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 14:43:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 13:43:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) References: Message-ID: New Merge Request !850 https://gitlab.com/gnutls/gnutls/merge_requests/850 Branches: tmp-fix-typos-in-lib 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 Fix some typos ## 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/850 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 17:55:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 16:55:13 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) References: Message-ID: New Merge Request !851 https://gitlab.com/gnutls/gnutls/merge_requests/851 Branches: tmp-update-gnulib 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 gnulib, remove two auto-generated files from repo, fix date for 'make syntax-check', update .gitignore. This all is related and thus in one commit. ## 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/851 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 18:08:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 17:08:31 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: @rockdaboot "maint.mk: out of date copyright in doc/gnutls.texi; update it" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850#note_128244029 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 18:33:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 17:33:58 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from rmbeer2@gmail.com): Fail Handsake (#649) In-Reply-To: References: Message-ID: This is the code that give the problem: https://stackoverflow.com/questions/53926500/i-need-to-run-gnutls-with-x509-in-server-client-doubts-and-needs-fixing -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/649#note_128245045 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 18:47:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 17:47:31 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: @lumag Yes, see my updated MR comment. That is addressed in !851 which needs to be merged first. I will then rebase !849 and !850 and force-push. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850#note_128245514 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 18:57:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 17:57:50 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: @rockdaboot what is the reason for removing `GNUMakefile`/`main.mk`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128245916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 18:58:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 17:58:55 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: It is an auto-generated file, created by `./bootstrap`. It will be included in the tarball automatically. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128245971 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 21:21:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 20:21:25 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) References: Message-ID: New Merge Request !852 https://gitlab.com/gnutls/gnutls/merge_requests/852 Branches: tmp-cipher-api-test-portable 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 Prerequisite for !809. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 1 22:59:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 01 Jan 2019 21:59:52 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: @rockdaboot This commit does not look good to me, no commit message and a mixture of changes. Maybe @nmav will approve it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128255222 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:01:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:01:06 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/slow/cipher-api-test.c: > if (ret < 0) > fail("could not add auth data\n"); > > - signal(SIGABRT, custom_abrt); > - ret = gnutls_cipher_add_auth(ch, data, 16); > - signal(SIGABRT, SIG_DFL); > - if (ret >= 0 && error_detected == 0) > - fail("succeeded in adding auth data data after partial data were given\n"); > + if (testmode == 1) { I cannot understand what testmode 1,2 mean from looking at the code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128306478 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:04:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:04:49 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/slow/cipher-api-test.c: > } else { > - test_cipher(algo,aead); > + test_cipher(algo, aead, testmode); > exit(0); > } > } > > void doit(void) > { > - start("aes128-gcm", GNUTLS_CIPHER_AES_128_GCM, 1); > - start("aes256-gcm", GNUTLS_CIPHER_AES_256_GCM, 1); > - start("aes128-cbc", GNUTLS_CIPHER_AES_128_CBC, 0); > - start("aes256-cbc", GNUTLS_CIPHER_AES_256_CBC, 0); > - start("3des-cbc", GNUTLS_CIPHER_3DES_CBC, 0); > + start("aes128-gcm", GNUTLS_CIPHER_AES_128_GCM, 1, 0); > + start("aes256-gcm", GNUTLS_CIPHER_AES_256_GCM, 1, 0); why called with testmode zero? This is supposed to do negative testing of `gnutls_cipher_add_auth`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128307115 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:09:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:09:20 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: I understand the reason for the change, though I do not understand the particulars of the change and it seems to be incorrect to me. It may be simpler to put this test into the list that cannot run in the alpine. That is, `--disable-bash-tests` made more general or in a similar option. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128320353 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:14:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:14:42 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: I also think that separating the commits is cleaner (e.g., especially for the doc). The removal of the auto-generated files could be mentioned in the commit. @lumag would that be ok? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128321391 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:15:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:15:18 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: @lumag You are right, I am at splitting into several smaller commits with explanations. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128321540 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:33:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:33:57 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: @lumag Updated, hope it looks better now :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128325159 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:41:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:41:03 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: The original code is already hard to understand. I didn't change the logic, but removed the SIGNAL stuff because that is not portable at all (has nothing to do with bash, but with kernel and libc). It might be a good idea to split the test into several smaller tests, WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128326747 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 10:50:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 09:50:08 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: This test checks whether the nettle signal is received from invalid use of gnutls calls. That is to test whether the re-implementations of ciphers (e.g., aes-gcm for ssse3) in gnutls behave the same as the nettle library. After the change, the signal is not received at all. Maybe just rename the `disable-bash-tests` to `disable-non-portable` tests? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128328658 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 11:46:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 10:46:55 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: > This test checks whether the abort signal is received from invalid use of gnutls calls. *AND* it also tests that the functions return error. In case assert() has *not* been called, the test still PASSes as long as an error is returned. Thus your above statement is technically wrong (or not 100% correct). My changes let assert() abort the program, and abortion is taken as success. I kept the code which checks the functions return value, just in case. If any of those cipher functions returns OK, the tests FAILs. So the functionality of the test has not changed - it just doesn't rely on SIGABRT signal handlers. I could add a check `WIFSIGNALED(status) && WTERMSIG(status) == SIGABRT` to make 100% sure that not anything else caused program abortion, if that is what you are missing. But if you like it better, I have no problem with going the `disable-non-portable` way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128352244 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 12:48:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 11:48:09 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: It's definitely much better now. Could you please fix the 7d9ea36ae4ca31cda478db01d0ed40dc5a6b8418 to actually drop those two files, I'll approve MR afterwards. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128364888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 13:30:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 12:30:12 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: Thanks, fixed now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851#note_128373269 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 13:54:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 12:54:04 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) References: Message-ID: New Merge Request !853 https://gitlab.com/gnutls/gnutls/merge_requests/853 Project:Branches: dueno/gnutls:tmp-msvc-fixes to gnutls/gnutls: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 Suggested by Gisle Vanem in: https://github.com/gnutls/gnutls/commit/fd8c1ec8fe155861dffa28811127f101b6697b4b#r31802648 ## 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/853 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 13:59:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 12:59:22 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) References: Message-ID: New Merge Request !854 https://gitlab.com/gnutls/gnutls/merge_requests/854 Branches: tmp-rsa-pss-tls12 to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes #645. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 14:22:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 13:22:19 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: >> This test checks whether the abort signal is received from invalid use of gnutls calls. > _AND_ it also tests that the functions return error. In case assert() has _not_ been called, the test still PASSes as long as an error is returned. Thus your above statement is technically wrong (or not 100% correct). Could be sorry. I think seeing the test it checks whether one of the two happens. Either an error is returned or an abort is seen. > My changes let assert() abort the program, and abortion is taken as success. I do not think that's the case. For example you skip the Additional data misuse in GCM ciphers, thus abort or error is not caught in that case. > So the functionality of the test has not changed - it just doesn't rely on SIGABRT signal handlers. I could add a check `WIFSIGNALED(status) && WTERMSIG(status) == SIGABRT` to make 100% sure that not anything else caused program abortion, if that is what you are missing. Ok, now I see that you rely on the fact that `check_wait_status()` does not fail on abort signal. I cannot think why `_check_wait_status()` would treat ABRT as success, and it may just be broken (thus you have uncovered a bug). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128384081 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 14:25:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 13:25:37 +0000 Subject: [gnutls-devel] GnuTLS | build: remove src/*.bak from distribution (!808) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: While [the linked bug](https://bugzilla.redhat.com/show_bug.cgi?id=1191904) looks interesting, IMO it doesn't directly mean ABI break, as the error comes from the libopts itself (not the dynamic linker), presumably in this part: http://git.savannah.gnu.org/cgit/autogen.git/tree/autoopts/init.c#n70 This indicates that libopts does versioning of the struct, in a similar manner as libtool's versioning, while it only takes into account of CURRENT and REVISION (i.e. equal to the latest interface version, not greater than). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_128384743 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 15:19:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 14:19:51 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: 10.11 for me. And yeap there is some similar issues in some libraries. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662#note_128397036 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 15:29:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 14:29:46 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: > For example you skip the Additional data misuse in GCM ciphers, thus abort or error is not caught in that case. Then I overlooked this special case and it's a regression in the MR (I'll have a look and would fix that). > I cannot think why `_check_wait_status()` would treat ABRT or any signal except sigterm as success, and it may just be broken (thus you have uncovered a bug). Ok, in this case I change the code to not call `_check_wait_status()` and instead use it's own check (which is trivial). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128399092 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 21:34:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 20:34:10 +0000 Subject: [gnutls-devel] libtasn1 | Detecting Bug in libtasn1-4.13 by fuzzing. (#4) In-Reply-To: References: Message-ID: @nmav Even though asn1Parser is the program used to demonstrate the vulnerability, that program just exercises the library. The vulnerability still exists in the lib itself and there could be an attack vector if a client of the lib could be induced to generate asn data that triggers it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/4#note_128461464 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 22:44:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 21:44:07 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: Merge Request !851 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/851 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 22:44:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 21:44:11 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!851) In-Reply-To: References: Message-ID: Merge Request !851 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/851 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/851 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 23:25:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 22:25:42 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from rmbeer2@gmail.com): Fail Handsake (#649) In-Reply-To: References: Message-ID: Why do you never respond to my request for help?? Do not you see that this is very important to me?? I need it!!! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/649#note_128484926 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 2 23:26:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 02 Jan 2019 22:26:27 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from rmbeer2@gmail.com): Fail Handsake (#649) In-Reply-To: References: Message-ID: need help with this!! https://stackoverflow.com/questions/53926500/i-need-to-run-gnutls-with-x509-in-server-client-doubts-and-needs-fixing -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/649#note_128485017 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 09:15:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 08:15:52 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls13_handshake_sign_data: properly fail on signing error (!855) References: Message-ID: New Merge Request !855 https://gitlab.com/gnutls/gnutls/merge_requests/855 Branches: tmp-fix-signing 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 When signing failed, gnutls would return an invalid signed message (with no data) instead of failing. ## 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/855 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 09:24:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 08:24:53 +0000 Subject: [gnutls-devel] libtasn1 | Detecting Bug in libtasn1-4.13 by fuzzing. (#4) In-Reply-To: References: Message-ID: Thank you for the insight, but you are wrong. In any case, please provide a fix if you believe this affects you. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/4#note_128570044 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:10:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:10:39 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/test-ciphers-api.sh (cipher-api-test.c) relies on undefined behavior of abort() (#623) In-Reply-To: References: Message-ID: Is that really the case? ``` -- Function: void abort (void) This function actually terminates the process by raising a ?SIGABRT? signal, and your program can include a handler to intercept this signal; see *note Signal Handling::. ``` https://www.gnu.org/software/libc/manual/html_mono/libc.html#Aborting-a-Program -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/623#note_128646434 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:16:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:16:16 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: Wait, let me challenge a little the change. I've commented directly on the issue #623 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852#note_128649191 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:34:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:34:19 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) References: Message-ID: New Merge Request !856 https://gitlab.com/gnutls/gnutls/merge_requests/856 Branches: tmp-tests-fail-on-signals 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 were only treating SIGSEGV as error though there is no reason to treat other signals as success and they may hide an actual error case (e.g., when SIGPIPE is received). With this change we treat any signals received by the child except SIGTERM as error, and we ensure that SIGPIPE is ignored in all tests. ## 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/856 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:34:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:34:54 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: @rockdaboot does the updated cipher-api-test work on alpine with musl? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128655385 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:36:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:36:15 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) In-Reply-To: References: Message-ID: Merge Request !853 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/853 Project:Branches: dueno/gnutls:tmp-msvc-fixes to gnutls/gnutls:master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/853 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 13:36:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 12:36:28 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) In-Reply-To: References: Message-ID: Looks good to me. It needs to be rebased on master for merging. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/853#note_128656325 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 14:00:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 13:00:33 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Cherry-picked + started this MR/commit + the tarball CI on Alpine: https://gitlab.com/rockdaboot/gnutls/pipelines/42006916 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128674116 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 14:56:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 13:56:58 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: It seems that an additional test is failing on the CI. I've amended the commit to fix that too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128691474 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 15:59:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 14:59:10 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: It looks good to me. Seeing that though, in the tls13 file we use `sign_supports_priv_pk_algorithm()` on the sign counter-parts. Should we do that here as well? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854#note_128708013 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 16:03:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 15:03:52 +0000 Subject: [gnutls-devel] libtasn1 | Detecting Bug in libtasn1-4.13 by fuzzing. (#4) In-Reply-To: References: Message-ID: @nmav Can you explain why I am wrong? I would like to understand why the library itself is not vulnerable. Couldn't a client of the library call asn1_parser2tree and provide invalid data? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/4#note_128709227 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 16:06:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 15:06:24 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: https://gitlab.com/rockdaboot/gnutls/pipelines/42023646 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128709934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 16:27:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 15:27:39 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: @nmav The mingw runners succeed after 5mins with 'nettle 3.4.1 not found'. We had that before... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128715260 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 16:55:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 15:55:47 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) References: Message-ID: New Merge Request !857 https://gitlab.com/gnutls/gnutls/merge_requests/857 Branches: tmp-unroll-ci-commands 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 The MinGW runners currently succeed though they fail (nettle not found). This fixes the runners (to report failure) by 'unrolling' concatenated shell commands (&&). ## 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/857 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 16:58:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 15:58:23 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: !857 fixes the wrong reporting of the runners. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128730134 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 17:03:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 16:03:19 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: There is already an f29 bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=1655398 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128731488 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 17:04:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 16:04:37 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: But I think unrolling is better readable/maintainable as well. And we don't have to wait and cross fingers... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128731846 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 17:06:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 16:06:14 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: @nmav That bug is about nettle. This MR is about the CI correctly reporting the build failure... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128732279 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 17:42:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 16:42:47 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: The Alpine runner doesn't have nettle 3.4.1 yet... I started a pipeline for build-images, maybe it's in now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128740552 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 18:53:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 17:53:08 +0000 Subject: [gnutls-devel] GnuTLS | Add support for EDDSA/Ed25519 object support via PKCS#11 (88377775) In-Reply-To: References: Message-ID: Marga Manterola started a new discussion on tests/testpkcs11.sh: > exit_error > fi > > +${P11TOOL} ${ADDITIONAL_PARAM} --list-machanisms ${TOKEN}|grep 25519 >/dev/null This includes a typo that causes the if to fail and output a bogus error. >From a Debian build: .../b4deb/src/.libs/p11tool: illegal option -- list-machanisms p11tool [options] [url] p11tool --help for usage instructions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/88377775a3eff679a9ec60ab9bfc6b3c683a0407#note_128758354 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 19:09:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 18:09:32 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: That makes sense; will update the patch. This MR is currently blocked by https://github.com/tomato42/tlsfuzzer/pull/490. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854#note_128762030 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 19:29:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 18:29:55 +0000 Subject: [gnutls-devel] GnuTLS | cipher-test-api fails 3des-cbc test when nettle is built in release mode (#665) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/665#note_128769531 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 20:52:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 19:52:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) References: Message-ID: New Merge Request !858 https://gitlab.com/gnutls/gnutls/merge_requests/858 Project:Branches: marga1/gnutls:master to gnutls/gnutls:master Author: Marga Manterola Assignee: The code checking for ed25519 support in testpkcs11.sh had a typo and was not actually checking for it, so it that test was never actually executed. This fixes the typo and will execute the test. ## 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/858 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 21:16:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 20:16:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) In-Reply-To: References: Message-ID: Merge Request !858 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/858 Project:Branches: marga1/gnutls:master to gnutls/gnutls:master Author: Marga Manterola Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/858 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 21:16:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 20:16:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) In-Reply-To: References: Message-ID: Merge Request !858 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/858 Project:Branches: marga1/gnutls:master to gnutls/gnutls:master Author: Marga Manterola Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/858 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 21:18:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 20:18:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) 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/858#note_128792113 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 21:35:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 20:35:56 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Found a way ... `cert-tests/certool` fails with ``` Generating a 3072 bit RSA private key... Generating a self signed certificate... error loading file at --load-privkey: certtool-file1.31992.tmp: Decryption has failed. cert generation failed FAIL certtool (exit status: 1) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128796318 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 21:37:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 20:37:22 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) In-Reply-To: References: Message-ID: Thanks for the quick merge! :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/858#note_128796472 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 22:41:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 21:41:05 +0000 Subject: [gnutls-devel] GnuTLS | Add support for EDDSA/Ed25519 object support via PKCS#11 (88377775) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on tests/testpkcs11.sh: > exit_error > fi > > +${P11TOOL} ${ADDITIONAL_PARAM} --list-machanisms ${TOKEN}|grep 25519 >/dev/null Ouch, I'll fix that -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/88377775a3eff679a9ec60ab9bfc6b3c683a0407#note_128816230 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 3 22:53:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 21:53:08 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo in 25519 detection command (!859) References: Message-ID: New Merge Request !859 https://gitlab.com/gnutls/gnutls/merge_requests/859 Project:Branches: simo5/gnutls:typofix to gnutls/gnutls:master Author: Simo Sorce Assignee: Obvious typo fix. ## 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/859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 00:51:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 23:51:52 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in doc/ (!849) In-Reply-To: References: Message-ID: Merge Request !849 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/849 Branches: tmp-fix-typos-in-doc to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/849 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 00:51:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 23:51:55 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in doc/ (!849) In-Reply-To: References: Message-ID: Merge Request !849 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/849 Branches: tmp-fix-typos-in-doc to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/849 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 00:53:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 23:53:40 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo in 25519 detection command (!859) In-Reply-To: References: Message-ID: Merge Request !859 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/859 Project:Branches: simo5/gnutls:typofix to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 00:54:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 03 Jan 2019 23:54:53 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo in 25519 detection command (!859) In-Reply-To: References: Message-ID: @simo5 please rebase to fix build issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/859#note_128840770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 01:03:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 00:03:35 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: I'd second merging this MR, maybe after nettle packages hit F29. It would be better to detect build failures in future. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128841411 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 03:12:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 02:12:57 +0000 Subject: [gnutls-devel] GnuTLS | Add support for EDDSA/Ed25519 object support via PKCS#11 (88377775) In-Reply-To: References: Message-ID: Marga Manterola commented on a discussion on tests/testpkcs11.sh: > exit_error > fi > > +${P11TOOL} ${ADDITIONAL_PARAM} --list-machanisms ${TOKEN}|grep 25519 >/dev/null I've fixed it already and the merge request has already been approved. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/88377775a3eff679a9ec60ab9bfc6b3c683a0407#note_128852217 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 07:53:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 06:53:58 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: I've updated the builders to include nettle 3.4.1 in mingw. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128887170 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 07:59:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 06:59:58 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Ok, let's separate the fix from the mingw failure or alpine (this should help as it uses SIGABRT as documented, but that's not the purpose of it). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128887916 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 08:01:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 07:01:31 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/minitasn1/coding.c: > /* der: string returned. */ > /* der_len: number of meaningful bytes of DER */ > /* (der[0]..der[ans_len-1]). Initially it */ > -/* if must store the lenght of DER. */ > +/* if must store the length of DER. */ Any changes in lib/minitasn1 will be overwritten by an update of libtasn1 files. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850#note_128888082 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 08:02:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 07:02:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: Other than the libtasn1 fixes which will be lost on next update, LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850#note_128888251 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 08:03:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 07:03:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: Merge Request !850 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/850 Branches: tmp-fix-typos-in-lib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 08:07:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 07:07:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo in 25519 detection command (!859) In-Reply-To: References: Message-ID: Merge Request !859 was closed by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/859 Project:Branches: simo5/gnutls:typofix to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 09:49:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 08:49:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/minitasn1/coding.c: > /* der: string returned. */ > /* der_len: number of meaningful bytes of DER */ > /* (der[0]..der[ans_len-1]). Initially it */ > -/* if must store the lenght of DER. */ > +/* if must store the length of DER. */ Right, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850#note_128904363 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 09:49:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 08:49:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: All discussions on Merge Request !850 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/850 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 10:03:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 09:03:34 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: > let's separate the fix from the mingw failure or alpine That's a good choice. I still don't get why a custom signal handler is needed: man assert: `assert() ... terminates the program by calling abort(3)` man abort: raises SIGABRT, but `If the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by restoring the default disposition for SIGABRT and then raising the signal for a second time.` This is POSIX behavior. If glibc doesn't behave like this, it is a bug. If it does, I don't understand why the code sets a variable in a signal handler. A check after a failed assert() doesn't make sense (except as a work-around for buggy glibc behavior). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128907131 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 10:05:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 09:05:42 +0000 Subject: [gnutls-devel] GnuTLS | PKCS#11: RSA-PSS should be enabled only when the private key can be used for signing (#667) References: Message-ID: New Issue was created. Issue 667: https://gitlab.com/gnutls/gnutls/issues/667 Author: Nikos Mavrogiannopoulos Assignee: In `gnutls_pkcs11_privkey_import_url()` we only enable RSA-PSS functionality to the key if the `CKM_RSA_PKCS_PSS` mechanism is available to the token. However, if the specific key is not marked for use with digital signatures (`CKA_SIGN` set), then we may still end-up using it which will later fail. We should test whether `CKA_SIGN` is set prior to enabling such keys for PSS. Furthermore we should make `CKA_SIGN/VERIFY` and `CKA_ENCRYPT/DECRYPT` visible via p11tool by amending `gnutls_pkcs11_obj_flags_get_str()`. [reported originally at: https://bugzilla.redhat.com/show_bug.cgi?id=1663058] -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/667 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 10:08:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 09:08:56 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: You are right the signal handler is not needed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_128908158 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 10:40:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 09:40:10 +0000 Subject: [gnutls-devel] libtasn1 | Detecting Bug in libtasn1-4.13 by fuzzing. (#4) In-Reply-To: References: Message-ID: `asn1_parser2tree()` is not called by users of the library. It is an API for use with the compile tools. You can see that in debian code search: https://codesearch.debian.net/search?q=asn1_parser2tree&perpkg=1 The only user is libtasn1 itself (the gnutls entry is because the libtasn1.h in the bundled minitasn1 lists this function, even though it is not in the bundled set). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/4#note_128914942 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 10:44:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 09:44:44 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) In-Reply-To: References: Message-ID: This commit didn't have the 'Signoff-by' tag. It seems that the regex we use for commit sanity didn't catch it. @marga.google would you like to agree explicitly on this commit to the [DCO 1.1](https://gitlab.com/gnutls/gnutls/blob/master/doc/DCO.txt)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/858#note_128915915 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 11:50:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 10:50:44 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) References: Message-ID: New Issue was created. Issue 668: https://gitlab.com/gnutls/gnutls/issues/668 Author: Tim R?hsen Assignee: Just an idea, if you agree I'll create an MR. We can easily check that Author's email matches with the email in Signed-off-by in every runner - it just takes 0.1s. It makes us independent of server side git hooks, which may work or not (out of our control, see !858). If it doesn't match, the complete pipeline would stop/error immediately and we wouldn't have to wait hours for a notification email. I suggest this little script: ``` #/usr/bin/env sh # create list of commits of the current branch commits=$(git rev-list --no-merges master..) # check if author's email matches email in 'Signed-off-by' for hash in $commits; do author=$(git log --format='%ae' ${hash}^\!) signed=$(git log --format='%b' ${hash}^\! | grep -i "Signed-off-by:") if test $? -ne 0; then echo "Missing Signed-off-by" exit 1 fi if ! echo $signed | grep -q "Signed-off-by:.*<${author}>"; then echo "Author '${author}' doesn't match" exit 1 fi done ``` If you agree, please let me know where to put it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 12:08:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 11:08:55 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: What about having it in the makefile and run the static analyzers run? E.g., `make commitcheck`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_128936064 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 12:12:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 11:12:41 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: The MinGW runners now fail due to some unrelated error: ``` doit:340: gnutls_x509_trust_list_add_trust_dir: 0 FAIL x509cert-tl.exe (exit status: 1) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128936867 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 13:30:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 12:30:51 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo when checking for ed25519 support (!858) In-Reply-To: References: Message-ID: Yes, I certify that the typo fix was created by me :). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/858#note_128954383 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 13:43:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 12:43:46 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Shell scripting in makefiles is ugly and adds another level of escaping. We could put the script into build-aux/ (btw, in my other projects I have a contrib/ directory for developer stuff) and call it via `make commitcheck`. WDYT ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_128957122 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 14:25:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 13:25:55 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: I saw it. It may be related to one of the following changes recently added. I've re-run their mingw targets in CI: https://gitlab.com/gnutls/gnutls/merge_requests/838 https://gitlab.com/gnutls/gnutls/merge_requests/839 https://gitlab.com/gnutls/gnutls/merge_requests/835 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128975265 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 14:29:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 13:29:23 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Seems good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_128976175 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 14:42:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 13:42:50 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: So !838 pass while !835 and !839 fail. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128979754 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 14:58:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 13:58:53 +0000 Subject: [gnutls-devel] GnuTLS | Add support for EDDSA/Ed25519 object support via PKCS#11 (88377775) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on tests/testpkcs11.sh: > exit_error > fi > > +${P11TOOL} ${ADDITIONAL_PARAM} --list-machanisms ${TOKEN}|grep 25519 >/dev/null Ah thanks, I'll close mine then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/88377775a3eff679a9ec60ab9bfc6b3c683a0407#note_128983817 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:00:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:00:07 +0000 Subject: [gnutls-devel] GnuTLS | PKCS#11: RSA-PSS should be enabled only when the private key can be used for signing (#667) In-Reply-To: References: Message-ID: Note that I have worked around this in OpenConnect thus: https://gitlab.com/openconnect/openconnect/merge_requests/23/diffs?commit_id=04bcebbc0658fdf36aa9b6572fdc529b74d751f5 The approach I've taken there covers all kinds of hardware keys, including TPM keys which may or may not support RSA-PSS. It just attempts to perform a RSA-PSS signature and then disables TLSv1.3 if that fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/667#note_128984089 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:00:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:00:27 +0000 Subject: [gnutls-devel] GnuTLS | Fix typo in 25519 detection command (!859) In-Reply-To: References: Message-ID: Dupliocate of !858 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/859#note_128984180 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:16:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:16:30 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) In-Reply-To: References: Message-ID: I mistakenly pushed this to my own fork, where `make abi-check` fails with git permission problems: https://gitlab.com/dueno/gnutls/-/jobs/141519814 Does anyone know how to fix this? Otherwise I will create a new MR based on the central repo. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/853#note_128987993 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:17:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:17:34 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) References: Message-ID: New Merge Request !860 https://gitlab.com/gnutls/gnutls/merge_requests/860 Branches: tmp-revert-835 to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This addresses CI failure in master. ## 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/860 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:19:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:19:03 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: I tried to isolate it to: !860 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857#note_128988608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:21:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:21:15 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!861) References: Message-ID: New Merge Request !861 https://gitlab.com/gnutls/gnutls/merge_requests/861 Branches: tmp-msvc-fixes to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This supersedes !853, for the CI problem. ## 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/861 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:21:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:21:53 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) In-Reply-To: References: Message-ID: Closing per !861. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/853#note_128989243 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:21:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:21:53 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!853) In-Reply-To: References: Message-ID: Merge Request !853 was closed by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/853 Project:Branches: dueno/gnutls:tmp-msvc-fixes to gnutls/gnutls:master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/853 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:23:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:23:43 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!861) In-Reply-To: References: Message-ID: Merge Request !861 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/861 Branches: tmp-msvc-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/861 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:34:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:34:58 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: @chouquette sorry for the spam, but we will have to revert this specific commit because it makes our CI tests fail under wine. It was not caught on the first MR because of the bug in gitlab (see https://gitlab.com/gitlab-com/support-forum/issues/1311 ). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860#note_128992366 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:37:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:37:13 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: @rockdaboot what do you think about reverting this to unblock CI? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860#note_128992874 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:43:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:43:55 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: Good thing :thumbsup: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860#note_128994504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 15:44:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 14:44:23 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: Merge Request !860 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/860 Branches: tmp-revert-835 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 16:36:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 15:36:08 +0000 Subject: [gnutls-devel] GnuTLS | tests/rng-op-key extrmely slow on the MinGW runners (#669) References: Message-ID: New Issue was created. Issue 669: https://gitlab.com/gnutls/gnutls/issues/669 Author: Tim R?hsen Assignee: The MinGW runners "hang" at `tests/rng-op-key` for 20+ minutes. Maybe the underlying random generator waits for events/entropy !? Looks like `gnutls_rnd()` needs a timeout value... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/669 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:11:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:11:16 +0000 Subject: [gnutls-devel] GnuTLS | tests/rng-op-key extrmely slow on the MinGW runners (#669) In-Reply-To: References: Message-ID: I noticed it too, though these are not new tests, and the mingw runners were much faster than their current speed. We may be seeing the same MR so hopefully it is a glitch. If it persists we should check whether we can make this test faster (e.g., less iterations but still test what it is supposed to test). btw. yes it calls the random generator but it shouldn't be waiting for entropy... said that, I think there was a recent MR changing the API used by the random generator in windows... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/669#note_129015520 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:12:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:12:11 +0000 Subject: [gnutls-devel] GnuTLS | Revert "verify-high2: Fix cert dir iteration on Win32" (!860) In-Reply-To: References: Message-ID: Merge Request !860 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/860 Branches: tmp-revert-835 to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/860 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:13:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:13:45 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!861) In-Reply-To: References: Message-ID: This may need a rebase on master due to some glibc in the mingw runners. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/861#note_129016156 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:15:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:15:11 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Removed the signal handlers, and updated to master in order to pass CI! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856#note_129016438 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:16:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:16:45 +0000 Subject: [gnutls-devel] GnuTLS | tests/rng-op-key extrmely slow on the MinGW runners (#669) In-Reply-To: References: Message-ID: No, the commit I had in mind was: https://gitlab.com/gnutls/gnutls/merge_requests/840/diffs?commit_id=cbedd86c1531d1d0bf02c2bd737951106c01fd87 and was not merged, so it is not that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/669#note_129016737 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 17:21:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 16:21:48 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Merge Request !856 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/856 Branches: tmp-tests-fail-on-signals to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 18:10:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 17:10:54 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) References: Message-ID: New Merge Request !862 https://gitlab.com/gnutls/gnutls/merge_requests/862 Branches: tmp-libopts-check to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This is a continuation of the discussion in: https://gitlab.com/gnutls/gnutls/merge_requests/808#note_124782407 In libopts there are two places where library versions are checked: at [source code level](http://git.savannah.gnu.org/cgit/autogen.git/tree/autoopts/tpl/opthead.tlib#n60) and [binary level](http://git.savannah.gnu.org/cgit/autogen.git/tree/autoopts/init.c#n75). These are basically the same condition, but we can't do much about the latter (e.g., copying a linked binary to older distributions). ## 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/862 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 20:53:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 19:53:19 +0000 Subject: [gnutls-devel] GnuTLS | tests: treat all signals as error (!856) In-Reply-To: References: Message-ID: Merge Request !856 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/856 Branches: tmp-tests-fail-on-signals to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/856 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 20:53:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 19:53:19 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/test-ciphers-api.sh (cipher-api-test.c) relies on undefined behavior of abort() (#623) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #623: https://gitlab.com/gnutls/gnutls/issues/623 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:12:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:12:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix typos in lib/ (!850) In-Reply-To: References: Message-ID: Merge Request !850 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/850 Branches: tmp-fix-typos-in-lib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/850 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:31:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:31:53 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: Merge Request !857 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/857 Branches: tmp-unroll-ci-commands to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:31:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:31:56 +0000 Subject: [gnutls-devel] GnuTLS | Unroll MinGW CI runner commands (!857) In-Reply-To: References: Message-ID: Merge Request !857 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/857 Branches: tmp-unroll-ci-commands to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/857 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:32:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:32:19 +0000 Subject: [gnutls-devel] GnuTLS | ext/pre_shared_key: avoid unnecessary use of VLA for MSVC (!861) In-Reply-To: References: Message-ID: Merge Request !861 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/861 Branches: tmp-msvc-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/861 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:38:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:38:40 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls13_handshake_sign_data: properly fail on signing error (!855) In-Reply-To: References: Message-ID: Merge Request !855 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/855 Branches: tmp-fix-signing to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/855 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:39:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:39:07 +0000 Subject: [gnutls-devel] GnuTLS | _gnutls13_handshake_sign_data: properly fail on signing error (!855) In-Reply-To: References: Message-ID: Merge Request !855 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/855 Branches: tmp-fix-signing to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/855 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 4 21:40:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 04 Jan 2019 20:40:26 +0000 Subject: [gnutls-devel] GnuTLS | tests/slow/cipher-api-test.c: Make test more portable (!852) In-Reply-To: References: Message-ID: Merge Request !852 was closed by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/852 Branches: tmp-cipher-api-test-portable to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/852 You're receiving 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 Jan 5 12:23:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 11:23:38 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668 You're receiving 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 Jan 5 12:24:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 11:24:58 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Closed by !844 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609#note_129107790 You're receiving 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 Jan 5 12:24:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 11:24:58 +0000 Subject: [gnutls-devel] GnuTLS | Issue with GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION (#609) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #609: https://gitlab.com/gnutls/gnutls/issues/609 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jan 5 14:15:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 13:15:20 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) References: Message-ID: New Merge Request !863 https://gitlab.com/gnutls/gnutls/merge_requests/863 Branches: tmp-fix-udp-serv to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This modifies the server to deinitialize the session after use (avoiding leaks), and to only send the hello verify request when a client hello is seen. This also adds a basic unit test of gnutls-serv with the --udp option. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests (general) ## 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/863 You're receiving 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 Jan 5 18:40:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 17:40:48 +0000 Subject: [gnutls-devel] libtasn1 | .gitlab-ci.yml: updated builders to latest used by gnutls (!7) References: Message-ID: New Merge Request !7 https://gitlab.com/gnutls/libtasn1/merge_requests/7 Branches: tmp-updated-builders to master Author: Nikos Mavrogiannopoulos Assignee: This updates the CI runners to the latest used by gnutls. ## Checklist * [x] Code modified for feature ## Reviewer's checklist: * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent with other code * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/merge_requests/7 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jan 5 20:31:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 19:31:32 +0000 Subject: [gnutls-devel] libtasn1 | Gcc 8 warns on buffer truncation (#6) In-Reply-To: References: Message-ID: Reassigned Issue 6 https://gitlab.com/gnutls/libtasn1/issues/6 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/6 You're receiving 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 Jan 5 20:52:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 19:52:41 +0000 Subject: [gnutls-devel] libtasn1 | .gitlab-ci.yml: updated builders to latest used by gnutls (!7) In-Reply-To: References: Message-ID: Merge Request !7 was merged Merge Request url: https://gitlab.com/gnutls/libtasn1/merge_requests/7 Branches: tmp-updated-builders to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/merge_requests/7 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jan 5 20:52:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 19:52:41 +0000 Subject: [gnutls-devel] libtasn1 | Gcc 8 warns on buffer truncation (#6) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #6: https://gitlab.com/gnutls/libtasn1/issues/6 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/6 You're receiving 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 Jan 5 20:52:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 05 Jan 2019 19:52:41 +0000 Subject: [gnutls-devel] libtasn1 | Gcc 8 warns on buffer truncation (#6) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #6: https://gitlab.com/gnutls/libtasn1/issues/6 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/6 You're receiving 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 Jan 6 17:58:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 06 Jan 2019 16:58:52 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) In-Reply-To: References: Message-ID: Thank you for investigating this further and making the test dynamic, without hardcoding libopts version in configure.ac. Please do not take this wrong, but I still do not understand the rationale for changing to the autogen setup in 3.6.5 at all. With 3.6.5 (the .bak-files-solution) building from GIT requires a local autogen, while building from the tarball allowed either rebuilding autogen stuff and linking against installed libopts or using the included autogened .bak-files and statically linking against the included libopts tearoff. Now you support linking against the installed libopts without re-generating autogened files, i.e. without autogen available. (OTOH the downside is that regenerating autogened files needs to be triggered manually by removing the stamp files.) Where is the win in this? As autogen/libopts is one source *I* thought it was a very uncommon setup to find libopts development files without autogen. And while regenerating the autogened is not super quick it is still not time consuming compared to the rest of the compiliation. TIA, cu Andreas -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/862#note_129230336 You're receiving 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 Jan 6 20:22:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 06 Jan 2019 19:22:51 +0000 Subject: [gnutls-devel] GnuTLS | idn2: do not use deprecated idn2_to_unicode_8z8z in idn2-2.1.0 (!864) References: Message-ID: New Merge Request !864 https://gitlab.com/gnutls/gnutls/merge_requests/864 Project:Branches: alonbl/gnutls:gnutls_3_5_x-idn2 to gnutls/gnutls:gnutls_3_5_x Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/864 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 16:21:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 15:21:26 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) In-Reply-To: References: Message-ID: > Now you support linking against the installed libopts without re-generating autogened files, i.e. without autogen available. While this is true, it was not the point of the change (!808). It was rather to simplify the Makefile logic by following the automake's practice in handling intermediate files (as in vala, texinfo, and lex/yacc). Nevertheless, > As autogen/libopts is one source I thought it was a very uncommon setup to find libopts development files without autogen. This is indeed true, and that makes the approach not really convincing. So I agree to switch back to including .bak files in the distribution. I hope there would be an easy option to bundle intermediate files through the upstream libopts.m4. @rockdaboot do you have any opinions? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/862#note_129423941 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 17:07:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 16:07:14 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) In-Reply-To: References: Message-ID: Sorry @dueno, I am mentally out. autogen/libopt is broken by design. I would never include such crap into any project - just think how many people were busy and how many working hours were spent on this in this project alone. Not counted the hours to get autogen/libopts into GnuTLS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/862#note_129463733 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 17:09:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 16:09:47 +0000 Subject: [gnutls-devel] build-images | Move to Alpine 3.9 for having nettle 3.4.1 (!15) References: Message-ID: New Merge Request !15 https://gitlab.com/gnutls/build-images/merge_requests/15 Branches: alpine-3.9 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/15 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 17:22:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 16:22:59 +0000 Subject: [gnutls-devel] build-images | Move to Alpine 3.9 for having nettle 3.4.1 (!15) In-Reply-To: References: Message-ID: Merge Request !15 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/15 Branches: alpine-3.9 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/15 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 19:08:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 18:08:18 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) References: Message-ID: New Merge Request !865 https://gitlab.com/gnutls/gnutls/merge_requests/865 Project:Branches: alonbl/gnutls:aclocal to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 7 23:06:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 07 Jan 2019 22:06:40 +0000 Subject: [gnutls-devel] GnuTLS | Fix _gnutls_write_new_general_name() result checking (!866) References: Message-ID: New Merge Request !866 https://gitlab.com/gnutls/gnutls/merge_requests/866 Project:Branches: maksqwe/gnutls:gnutls_write_new_general_fix to gnutls/gnutls:master Author: Maks Naumov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/866 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 11:20:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 10:20:05 +0000 Subject: [gnutls-devel] GnuTLS | Do not send extensions length field if there are no extensions (!867) References: Message-ID: New Merge Request !867 https://gitlab.com/gnutls/gnutls/merge_requests/867 Project:Branches: dwmw2/gnutls:emptyext to gnutls/gnutls:master Author: David Woodhouse Assignee: Since GnuTLS 3.6.3 we have started sending a zero-length list of extensions in ServerHello when there are none, instead of omitting the list entirely. This upsets the Cisco AnyConnect client as discussed in https://gitlab.com/openconnect/ocserv/merge_requests/92 ## 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/867 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 11:32:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 10:32:39 +0000 Subject: [gnutls-devel] GnuTLS | Fix _gnutls_write_new_general_name() result checking (!866) In-Reply-To: References: Message-ID: Please increase the CI timeout in `Settings/CI-CD/General Pipelines` to 3h and restart the failed runners. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/866#note_129687226 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 11:32:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 10:32:53 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Please increase the CI timeout in `Settings/CI-CD/General Pipelines` to 3h and restart the failed runners. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_129687293 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 12:22:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 11:22:29 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from mailloux@gmail.com): wat (#670) In-Reply-To: References: Message-ID: I'd suggest to check your certificates and OCSP responses for the site you have issues with. Please provide more information if you believe that's a gnutls issue and in that case please re-open the request. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/670#note_129702066 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 12:22:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 11:22:30 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from mailloux@gmail.com): wat (#670) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #670: https://gitlab.com/gnutls/gnutls/issues/670 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/670 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 12:31:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 11:31:58 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) References: Message-ID: New Merge Request !868 https://gitlab.com/gnutls/gnutls/merge_requests/868 Branches: tmp-fix-regression-ext-size 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 When sending no extensions do not include a zero length According to RFC5246: ``` The presence of extensions can be detected by determining whether there are bytes following the compression_method field at the end of the ServerHello. ``` and as such we correct our behavior to not send the zero length bytes. This was our behavior in 3.5.x and 3.3.x branch, and thus this corrects a regression of gnutls with these branches. ## Checklist * [x] Code modified for feature * [x] 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/868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 12:35:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 11:35:31 +0000 Subject: [gnutls-devel] GnuTLS | Do not send extensions length field if there are no extensions (!867) In-Reply-To: References: Message-ID: Ooops I didn't see this MR before trying to make a fix. What do you think about !868? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/867#note_129705485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 12:53:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 11:53:08 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Yeah, that fixes it. I was about to do the same in my own MR but wasn't sure if it was right to do this for *all* users of `_gnutls_extv_append_final()` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129709837 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 13:06:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 12:06:54 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Argh, no. Both this and my version are breaking the OpenSSL client. ``` SSL connection failure 140182920185984:error:141BC09F:SSL routines:tls_process_encrypted_extensions:length mismatch:ssl/statem/statem_clnt.c:3689: ``` Looks like I have one version of OpenSSL which *requires* zero-length extensions list and one which requires it to be absent when it's zero-length? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129713484 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 13:33:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 12:33:32 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: That affects OpenSSL 1.1.1 but not 1.1.0 AFAICT. I think it's a bug. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129720467 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 13:39:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 12:39:39 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Er... except this is probably doing TLSv1.3. Are the extensions still optional there? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129722012 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 13:47:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 12:47:52 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: I think this fixes it: https://gitlab.com/gnutls/gnutls/merge_requests/867/diffs?commit_id=f00952b2dc3c7352f75eb40e085c94b1d2a5d3d5 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129724356 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 14:49:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 13:49:03 +0000 Subject: [gnutls-devel] GnuTLS | Revert "build: remove src/*.bak from distribution" (!869) References: Message-ID: New Merge Request !869 https://gitlab.com/gnutls/gnutls/merge_requests/869 Branches: tmp-autogen-bak-revert 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 See the discussion on !862. ## 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/869 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 14:51:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 13:51:07 +0000 Subject: [gnutls-devel] GnuTLS | Fix _gnutls_write_new_general_name() result checking (!866) In-Reply-To: References: Message-ID: done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/866#note_129743468 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 14:52:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 13:52:26 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) In-Reply-To: References: Message-ID: OK, let's move back to the working solution then; closing per !869. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/862#note_129743857 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 14:52:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 13:52:26 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check libopts version more strictly (!862) In-Reply-To: References: Message-ID: Merge Request !862 was closed by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/862 Branches: tmp-libopts-check to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/862 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 15:20:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 14:20:50 +0000 Subject: [gnutls-devel] GnuTLS | Fix _gnutls_write_new_general_name() result checking (!866) In-Reply-To: References: Message-ID: Merge Request !866 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/866 Project:Branches: maksqwe/gnutls:gnutls_write_new_general_fix to gnutls/gnutls:master Author: Maks Naumov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/866 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 15:20:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 14:20:53 +0000 Subject: [gnutls-devel] GnuTLS | Fix _gnutls_write_new_general_name() result checking (!866) In-Reply-To: References: Message-ID: Merge Request !866 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/866 Project:Branches: maksqwe/gnutls:gnutls_write_new_general_fix to gnutls/gnutls:master Author: Maks Naumov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/866 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:17:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:17:30 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: @dwmw2 thank you, merged it with this patch because the CI doesn't work in !867. I added an explicit Signed-off-by as it was not on the original patch, could you please verify that this is ok? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129915414 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:18:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:18:44 +0000 Subject: [gnutls-devel] GnuTLS | Do not send extensions length field if there are no extensions (!867) In-Reply-To: References: Message-ID: Merged in !868 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/867#note_129915611 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:18:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:18:44 +0000 Subject: [gnutls-devel] GnuTLS | Do not send extensions length field if there are no extensions (!867) In-Reply-To: References: Message-ID: Merge Request !867 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/867 Project:Branches: dwmw2/gnutls:emptyext to gnutls/gnutls:master Author: David Woodhouse Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/867 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:21:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:21:26 +0000 Subject: [gnutls-devel] GnuTLS | idn2: do not use deprecated idn2_to_unicode_8z8z in idn2-2.1.0 (!864) In-Reply-To: References: Message-ID: Hi Alon, there is no plan for another 3.5.x release as the 3.6.x has become the new stable branch. If you have any comments about this process I'd like to invite you to provide your input in #651 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/864#note_129916077 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:21:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:21:55 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: Reassigned Issue 632 https://gitlab.com/gnutls/gnutls/issues/632 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:24:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:24:48 +0000 Subject: [gnutls-devel] GnuTLS | CertificateVerify msg with rsae private_key and rsa-pss signature scheme. (#645) In-Reply-To: References: Message-ID: Reassigned Issue 645 https://gitlab.com/gnutls/gnutls/issues/645 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:24:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:24:56 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert for malformed Client Hello (#659) In-Reply-To: References: Message-ID: Reassigned Issue 659 https://gitlab.com/gnutls/gnutls/issues/659 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/659 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:25:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:25:26 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert for malformed Client Hello (#659) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/659 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:26:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:26:45 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Reassigned Merge Request 854 https://gitlab.com/gnutls/gnutls/merge_requests/854 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:26:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:26:51 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:28:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:28:47 +0000 Subject: [gnutls-devel] GnuTLS | idn2: do not use deprecated idn2_to_unicode_8z8z in idn2-2.1.0 (!864) In-Reply-To: References: Message-ID: Hi Nikos, Isn't this premature to have 3.6.x as the only stable? I can confirm that we found almost no issues with it, but I would have given it some more time as there were significant changes. If you ever release, consider this patch as well. Thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/864#note_129917258 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:38:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:38:18 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Merge Request !854 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/854 Branches: tmp-rsa-pss-tls12 to master Author: Daiki Ueno Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:38:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:38:59 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Thank you. I've added a trivial optimization in one of these functions (that `se` now resolved) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854#note_129919018 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:39:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:39:36 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Reassigned Merge Request 854 https://gitlab.com/gnutls/gnutls/merge_requests/854 Assignee changed from Nikos Mavrogiannopoulos to Unassigned -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:45:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:45:42 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on Makefile.am: > SUBDIRS += doc > endif > > -ACLOCAL_AMFLAGS = -I m4 -I src/libopts/m4 -I src/gl/m4 -I lib/unistring/m4 > +ACLOCAL_AMFLAGS = -I m4 -I src/libopts/m4 -I src/gl/m4 -I lib/unistring/m4 --install Doesn't this make however building unpredictable? I remember in the past (before ./bootstrap) on certain occasions I would see different m4 files and different behavior in different build systems. Not sure how big the problem would be (or if it will be) as we still have the CI builders, but I worry that for the system that may make the release. What are you trying to avoid? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_129922219 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:46:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:46:40 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Yes, thanks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_129922380 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:55:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:55:32 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: It seems to recommended since automake 1.10, see https://www.manpagez.com/info/automake/automake-1.10/automake_43.php (search for --install and start with the paragraph above). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_129923842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 20:58:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 19:58:54 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: As far as I understand m4/*.m4 are already distributed, and macros from /usr/share/aclocal/*.m4 that are being used are copied into aclocal.m4. Hence, the distribution tarball includes all m4 macros required for build. The configure script is generated using these macros. Performing autoreconf while all macros exist in m4/*.m4 is adding predictability, as running aclocal or autoreconf find these macros and not look for them in system. The problem I have is that the guile.m4 of your build system, supports only 1.8 and 2.0, while we need support of 2.2, this can be done by using the guile.m4 of the guile-2.2. Because the m4/ directory is missing some of the macros, running aclocal/autoreconf tries to regenerate aclocal.m4, this means that all dependencies that provide m4 macros must be installed even if they are not used. Having all macros in m4 directory will somewhat make it easier for downstream to patch the package. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_129924378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 8 21:32:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 08 Jan 2019 20:32:00 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Hmmm, but what if downstream just has guile 1.8 or 2.0 ? Is it save to always use latest m4 with older software ? Or isn't it - in the end - easier for downstream to have their own development environment ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_129931504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 05:53:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 04:53:56 +0000 Subject: [gnutls-devel] GnuTLS | tests/rng-op-key extrmely slow on the MinGW runners (#669) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/669 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 07:45:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 06:45:44 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: This is a change in guile.m4, it limits the versions it searches, this not have been the case in the past. It searches to older compatible versions up to the recent one. If downstream replaces the guile.m4, let's say with the 2.2, and performing autoreconf and package builds/pass tests/works then it is should be safe. What we need is a simple method of doing so. Currently to execute aclocal gtk-doc must be installed, which is huge dependency just to fix the guile, so I must sed the configure, which is a method I would like to avoid. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_130029990 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 07:47:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 06:47:06 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect alert for malformed Client Hello (#659) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #659: https://gitlab.com/gnutls/gnutls/issues/659 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/659 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 07:47:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 06:47:06 +0000 Subject: [gnutls-devel] GnuTLS | CertificateVerify msg with rsae private_key and rsa-pss signature scheme. (#645) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #645: https://gitlab.com/gnutls/gnutls/issues/645 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 07:47:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 06:47:06 +0000 Subject: [gnutls-devel] GnuTLS | tls-sig: check RSA-PSS signature key compatibility also in TLS 1.2 (!854) In-Reply-To: References: Message-ID: Merge Request !854 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/854 Branches: tmp-rsa-pss-tls12 to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 08:27:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 07:27:57 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PKCS11_TOKEN_MODNAME is unavailable when a provider is manually loaded (#633) In-Reply-To: References: Message-ID: `p11_kit_module_get_name()` returns the configured name for the module in p11-kit. I think we should either document this issue, or decide what we could return in case the module is loaded manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/633#note_130039592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 08:30:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 07:30:38 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Ok, no objection with `--install`; if we have issues we can reconsider. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865#note_130040113 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 09:30:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 08:30:17 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/868 was reviewed by David Woodhouse -- David Woodhouse started a new discussion on tests/no-extensions.c: > +/* > + * Copyright (C) 2008-2012 Free Software Foundation, Inc. 2012? FSF? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:04:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:04:22 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/no-extensions.c: > +/* > + * Copyright (C) 2008-2012 Free Software Foundation, Inc. Ooops, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868#note_130226788 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:19:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:19:54 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Merge Request !868 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/868 Branches: tmp-fix-regression-ext-size to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:20:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:20:12 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) 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/868#note_130232929 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:22:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:22:23 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Merge Request !865 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/865 Project:Branches: alonbl/gnutls:aclocal to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:22:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:22:48 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: All discussions on Merge Request !865 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/865 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:22:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:22:52 +0000 Subject: [gnutls-devel] GnuTLS | build: install all m4 macros (!865) In-Reply-To: References: Message-ID: Merge Request !865 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/865 Project:Branches: alonbl/gnutls:aclocal to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:50:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:50:41 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) 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/868#note_130242508 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:50:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:50:56 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: All discussions on Merge Request !868 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/868 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:52:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:52:16 +0000 Subject: [gnutls-devel] GnuTLS | idn2: do not use deprecated idn2_to_unicode_8z8z in idn2-2.1.0 (!864) In-Reply-To: References: Message-ID: Merge Request !864 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/864 Project:Branches: alonbl/gnutls:gnutls_3_5_x-idn2 to gnutls/gnutls:gnutls_3_5_x Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/864 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 16:53:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 15:53:49 +0000 Subject: [gnutls-devel] GnuTLS | idn2: do not use deprecated idn2_to_unicode_8z8z in idn2-2.1.0 (!864) In-Reply-To: References: Message-ID: The reason is mainly to reduce the number of supported branches/releases. On the issue above, I propose to have only a single stable/lts branch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/864#note_130243507 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 18:35:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 17:35:30 +0000 Subject: [gnutls-devel] GnuTLS | When sending no extensions do not include a zero length (!868) In-Reply-To: References: Message-ID: Merge Request !868 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/868 Branches: tmp-fix-regression-ext-size to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 18:36:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 17:36:22 +0000 Subject: [gnutls-devel] GnuTLS | Revert "build: remove src/*.bak from distribution" (!869) In-Reply-To: References: Message-ID: Merge Request !869 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/869 Branches: tmp-autogen-bak-revert to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/869 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 18:36:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 17:36:59 +0000 Subject: [gnutls-devel] GnuTLS | Revert "build: remove src/*.bak from distribution" (!869) In-Reply-To: References: Message-ID: Hopefully we can simplify that in the future. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/869#note_130276378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 18:38:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 17:38:09 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Here there is `devel/` for devel only items. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_130276633 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 20:54:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 19:54:21 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Will find some time in the next days... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_130311950 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 9 20:56:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 09 Jan 2019 19:56:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: This MR adds ca. 18 mins to the CI. I suggest we further reduce the time of the test suite and then go ahead... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130312320 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 07:59:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 06:59:57 +0000 Subject: [gnutls-devel] GnuTLS | The flag %NO_EXTENSIONS is disabling extension support while being functional (!870) References: Message-ID: New Merge Request !870 https://gitlab.com/gnutls/gnutls/merge_requests/870 Branches: tmp-fix-no-extensions to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list That is, the %NO_EXTENSIONS option is the only documented way to disable extensions completely from a session. Clarify that message, mention that its behavior is undefined when combine with TLS1.3, and make sure that it is functional. The latter makes sure that safe renegotiation and extended master secret extensions remain disabled when this flag is given. That simplifies testing certain scenarios under TLS1.0 or TLS1.1 when no extensions must be used. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/870 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 14:49:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 13:49:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Should we separate alpine from the 2nd stage? Alpine itself shouldn't add time to the CI. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130519252 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 15:45:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 14:45:38 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: I tested 2 approaches, a stage 0 and calling the script in 'before_script:' The first approach add another 38-54s to the pipeline (depends on the Gitlab infrastructure perfomance). The good side is that a contributor sees an error after this short time - if `Signed-off-by` has been forgotten. The second approach adds no time to the pipeline, but it may take a while before each runner starts and errors. The duration depends on the Gitlab infrastructure perf, and took 12 minutes before it finished. This is due to retries of some runners, due to large docker images to load and due to large ccache archives to load and extract. Let me know your thoughts and preference. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_130540030 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 17:22:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 16:22:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: The second stage is needed for a real tarball test, without dev tools installed. That is `docker-alpine-base` in the build-images repo. Apart from that, we can add an Alpine dev runner, let's call it `docker-alpine`. We just make a copy of `docker-alpine-base` and add the needed dev packages (ca the same as for Debian x86_64). Maybe we can request a finer tunable `stage` system for Gitlab.com. Something like 'parallel' stages, where the tarball runner starts as soon as the tarball has been created. Or we start a 'docker run ...' within a runner to do exactly that !? That would be pretty cool, WDYT ? https://blog.docker.com/2013/09/docker-can-now-run-within-docker/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130586411 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 19:18:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 18:18:09 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: I'd avoid the stages for this. Initially we had the `make syntax-check` and other simple tests in a stage 0 but it caused many more delays than expected in the scenario where you had to wait long (an hour or two because free runners were taken) for the first runner, and by the time you got to stage 1, other projects had got the free runners. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_130615386 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 19:38:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 18:38:56 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: I think the stages approach would require a lot of experimentation and thinking before we deploy it, while an alpine build could be more easily added and would have its benefits seen immediately. The second stage is tricky: it will add a fixed amount of delay in all builds, and for only make dist and make && make check, it seems an overkill. That's because it could run at stage0 after one build (btw. we already have `make distcheck`, isn't that testing this scenario?). Said that I still think that a second stage with more advanced checks may be useful though that may be a very long discussion and even harder to implement without moving our CI outside the acceptable limit of 1h. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130621861 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 19:39:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 18:39:21 +0000 Subject: [gnutls-devel] GnuTLS | Revert "build: remove src/*.bak from distribution" (!869) In-Reply-To: References: Message-ID: Merge Request !869 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/869 Branches: tmp-autogen-bak-revert to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/869 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 21:15:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 20:15:29 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: > Initially we had the make syntax-check and other simple tests in a stage 0 but it caused many more delays Well, of course. `make syntax-check` needs a full bootstrap, configure and make cycle. That might easily take 10 minutes. But anyways, I'll prepare an MR without introducing stage 0. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_130643764 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 21:27:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 20:27:14 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) References: Message-ID: New Merge Request !871 https://gitlab.com/gnutls/gnutls/merge_requests/871 Branches: tmp-check-if-signed2 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 #668 ## 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/871 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 21:34:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 20:34:50 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: @nmav On the FreeBSD runner, the commit author seems to be always you. That means the check script fails since it compares author's and signer's email - they both must match. Can you fix it on your side ? Else I have to introduce an ugly work-around... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130646741 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:23:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:23:13 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: The freebsd runner runs as a normal user with ssh if that helps. I wouldn't know why the git log would show me as committer. there is nothing special setup. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130654759 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:24:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:24:05 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: btw. why do you run it on freebsd? seeing it further, does it really need to run to all runners? It would be fine if it runs in only one of them, e.g., the static analyzers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130654878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:28:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:28:17 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: It has to run on all runners (I already explained it somewhere) to stop all runners on error (= missing / wrong Signed-off-by). Else we need a stage 0. Or is there a trick to stop the whole pipeline on error ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130655454 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:29:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:29:25 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: Regarding the FreeBSD runner: Can you start it manually and run the script ? Then check for author / signer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130655612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:37:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:37:14 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: Looks like Alpine doesn't package autogen / libopts. Building from git repo fails due to that. Did I say that autogen/libopts becomes tedious !? :-( -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130657188 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 22:55:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 21:55:23 +0000 Subject: [gnutls-devel] build-images | Add Alpine runner (!16) References: Message-ID: New Merge Request !16 https://gitlab.com/gnutls/build-images/merge_requests/16 Branches: tmp-docker-alpine to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/16 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 10 23:02:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 10 Jan 2019 22:02:59 +0000 Subject: [gnutls-devel] build-images | Add Alpine runner (!16) In-Reply-To: References: Message-ID: Merge Request !16 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/16 Branches: tmp-docker-alpine to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/build-images/merge_requests/16 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 07:35:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 06:35:10 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) References: Message-ID: New Merge Request !872 https://gitlab.com/gnutls/gnutls/merge_requests/872 Branches: tmp-authors 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 The original file was unmaintained since long time. This is now auto-generated from the git shortlog, at release time. Relates #606 ## 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/872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 07:49:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 06:49:46 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: This is based on the commits, maybe one based on the lines of code present would be more accurate, but I don't know whether there is some tool that could get that info. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_130720218 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 07:57:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 06:57:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: With the reversal of `.bak` removal, can't we compile without autogen now? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130721471 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 07:59:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 06:59:20 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: Why do we need to stop all runners on error? There can be different errors revealed by different runners. That's the approach we have now. The freebsd runner is an image in amazon, I don't have easy access to it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130721785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 09:37:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 08:37:15 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: As a contributor you push to your own fork of GnuTLS and then wait for CI success/error. Gitlab sends you an email after error. If you just forgot Signed-off-by, it would be nice to get this email after a few seconds and not after 2 hours... That email is only sent after *all* runners are finished. So if we continue even one single runner, the email is delayed for 1-2h. To avoid this productivity-killing nonsense, all runners have to stop in case Singed-off-by is missing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130741091 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 09:38:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 08:38:54 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: When exactly was it reversed ? The fresh git clone 11 hours ago didn't have .bak files, AFAICS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_130741509 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 12:48:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 11:48:47 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: I see that this is very important to you. I see it different, I see it the same as the errors output by `make syntax-check`. Doing the devil's advocate, if I do a push to the CI to see the errors, I can return an hour later seeing that no errors were reported because the `Signoff-by` was missing. Anyway I do not know how to help you here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130809014 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 13:19:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 12:19:56 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: IMO, it helps the GnuTLS project if we reduce the CI turnaround times. At least I can't wait an hour or so for a result, when further work is based on the results. I personally have the impression that development performance is pretty slow. Waiting 1-2 hours for a trivial change to be checked is tedious. The 'Signed-off-by' issue is just symptomatic (and not so important to me as stand-alone issue). In my professional environment, I make like 10-30 commits a day and then run a complete test. Mostly starting the tests when I leave the office to have results in the morning. At GnuTLS I am at 1 commit every two days, mostly because of long-running CI (and discussions of course, which is ok). It feels like being very unproductive. Another point is that - of course - I won't wait for the CI, but start new work on other projects, which often pulls me in for hours or days. It is then hard to remember or to continue the work at GnuTLS - especially when CI runners needs to be restarted several times due to 137 errors or whatever. Not sure if we have time enough at FOSDEM, but I suggest a brainstorming on how to improve CI / testing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130823932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 14:11:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 13:11:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Reduce capi usage (!840) In-Reply-To: References: Message-ID: Hi, sorry about the delay in replying. Given MS track record when it comes to backward compatibility, I don't think CAPI will go away anytime soon (if at all) for Desktop apps. That being said, CAPI is already gone for UWP apps. I couldn't find something else than https://docs.microsoft.com/en-us/windows/desktop/seccng/cng-portal when it comes to CAPI deprecation/advise to use NCrypt/BCrypt > why is Microsoft introducing new API? etc. My guess is as good as yours :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/840#note_130843909 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 14:12:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 13:12:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Reduce capi usage (!840) In-Reply-To: References: Message-ID: Hugo Beauz?e-Luyssen commented on a discussion on lib/system/keys-win.c: > goto cleanup; > } > } else { > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) I pushed a new commit splitting the fallback in a separated function. If that's what you had in mind, I'll squash the 2 commits later on. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/840#note_130844353 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 14:56:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 13:56:31 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: Certainly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130858955 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 15:00:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 14:00:06 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: To start brainstorming about the 137 errors, maybe we should increase the retries to 2 (max). I suspect that retries 1 that we have now doesn't retry any job. However this may increase the total running time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130860029 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 15:18:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 14:18:46 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: In my tests with the Signed-off-by stuff I saw that 'retry: 1' indeed restarts the runners when they fail. But I am not sure about error 137. It might be a different category. To test it, we could wget an URL (with runner/pipeline id) and check the logs of the web server next time we see 137. Currently, I have no web server running... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_130868666 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 11 15:37:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 11 Jan 2019 14:37:21 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) References: Message-ID: New Merge Request !873 https://gitlab.com/gnutls/gnutls/merge_requests/873 Project:Branches: ansasaki/gnutls:fix_fips_lib_name to gnutls/gnutls:master Author: Anderson Sasaki Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. This is a fix for a bug originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1665061 There were 2 issues: * The libraries names in libs/fips.c have not been updated when the sonames were bumped: ``` libgnutls.so.28 -> libgnutls.so.30 libnettle.so.4 -> libnettle.so.6 libhogweed.so.2 -> libhogweed.so.4 ``` * The decoding of the HMAC fails when there is a '\n' at the end of the file. The newline makes the file to hold 65 bytes instead of the expected 64 bytes. At the end of the processing (lib/extras/hex.c:39) it checks if all input bytes were processed, but the last remaining byte makes the check to fail. This is not exactly a bug, but allowing newlines at the end of the file makes the format of the accepted files more flexible, and the integrity check more robust. ## 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/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 Sat Jan 12 16:46:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 12 Jan 2019 15:46:47 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) References: Message-ID: New Issue was created. Issue 672: https://gitlab.com/gnutls/gnutls/issues/672 Author: Matthias Gierlings Assignee: ## Description of problem: ## Version of gnutls used: ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) ## How reproducible: Steps to Reproduce: * one * two * three ## Actual results: ## Expected results: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672 You're receiving 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 Jan 12 17:04:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 12 Jan 2019 16:04:13 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Apparently my original post was overwritten by the bug template, when I inserted the headline and selected the "Bug" category *after* authoring the problem description, solved through edit. Sorry for the additional noise. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_131050371 You're receiving 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 Jan 12 18:18:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 12 Jan 2019 17:18:25 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Seems to relate to https://gitlab.com/gitlab-org/gitlab-ce/issues/44001 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_131055731 You're receiving 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 Jan 12 19:13:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 12 Jan 2019 18:13:04 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Those discussions are 10 months old. Pretty unlikely they result in action on Gitlab's side. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_131059257 You're receiving 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 Jan 12 19:21:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 12 Jan 2019 18:21:52 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: @nmav I am just thinking about an additional runner for lightweight tasks like this check and e.g. spell-checking, ... all the things that need just a few seconds or less. Are you OK with that ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_131059819 You're receiving 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 Jan 13 09:56:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 13 Jan 2019 08:56:30 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 (Dec 1, 2018?Jan 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672 You're receiving 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 Jan 13 10:00:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 13 Jan 2019 09:00:32 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Thank you for bringing that up. The fixes look simple. I think it would be beneficial to have something like that automated in our CI. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_131093450 You're receiving 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 Jan 13 14:51:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 13 Jan 2019 13:51:57 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Being able to find such issues as part of a CI run would indeed be a nice feature, however there are some obstacles. Results like this have been discovered through evolutionary fuzzing techniques. In order for this to produce results multiple instances need to run for days or weeks, which is usually not desirable as part of the regular CI run. In order to resolve the issue across the entire code base and not only w.r.t. ECDHE I'd suggest the following steps: 1. Identify the code locations that are responsible for sending TLS Alerts 2. Make sure that upon receipt of a fatal alert the connection is immediately terminated. Do not respond with any alerts of your own.*(1) 3. Use you IDE or tools like ctags/cscope to identify all code locations that call the code locations identified in step 1. 4. Review the alert type selected by the code locations identified in step 3. If this alert type is an `INTERNAL_ERROR` it is *very* likely it needs to be replaced with an appropriate protocol related alert. Cases where sending an INTERNAL_ERROR would be OK are for instance: - A memory allocation request to the OS failed - Starting a thread or forking a process failed - A write to disk failed (i.e. because the hard drive is full) - ... (*1) Side note: You may send alerts in response to non fatal alerts. Be aware however that sending a non fatal alert puts you in a situation where you can not foresee how the peer will react. Section 7.2.2 in RFC 5246 states ``` If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection. Given this, the sending party cannot, in general, know how the receiving party will behave. Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted. For example, if a peer decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a certificate_expired alert. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_131126590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 08:49:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 07:49:05 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Of course, let's try it and see how it goes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668#note_131214137 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 10:22:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 09:22:22 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) References: Message-ID: New Merge Request !874 https://gitlab.com/gnutls/gnutls/merge_requests/874 Branches: tmp-check-if-signed 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 Add another runner to only check for `Signed-off-by:` in new commit messages. Obsoletes !871 ## 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/874 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 10:22:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 09:22:46 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: Merge Request !871 was closed by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/871 Branches: tmp-check-if-signed2 to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 10:22:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 09:22:47 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!871) In-Reply-To: References: Message-ID: Replaced by !874 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/871#note_131238283 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 10:58:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 09:58:21 +0000 Subject: [gnutls-devel] GnuTLS | certtool: data encipherment is disabled by default (!875) References: Message-ID: New Merge Request !875 https://gitlab.com/gnutls/gnutls/merge_requests/875 Branches: tmp-fix-certtools 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 For the TLS protocol this option is not necessary, and if enabled by mistake (as default) and no other option is set, then the generated key will be unusable. Thus we disable it, to generate working keys by default. ## 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/875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 11:20:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 10:20:39 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) References: Message-ID: New Issue was created. Issue 673: https://gitlab.com/gnutls/gnutls/issues/673 Author: Ludio Assignee: first of all i want to thank all people involved in gnutls library providing this critical piece of software. well done! my question is regarding the possibility to use gnutls over custom transport network. i went over all examples and i could not find a way to use gnutls in this way. custom transport means that i have a small library which provides a layer of abstraction of the i/o system. therefore i have the possibility to use linux sockets or some other specific hardware. i saw gnutls provides api for setting push/pull functions which does the sending/receiving part but unfortunately for me they expect similar blocking behavior as send/recv from linux. gnutls_transport_set_pull_function/gnutls_transport_set_push_function is the api i am referring to. i try to provide as scheme of the issue. 1. what gnutls has |gnutls| <-> |linux sockets| 2. what gnutls has with cbs |gnutls| <-> |callbacks with blocking behavior| <-> |linux sockets| 3. what i have | appl | <-INTER-> | ct lib nb | <-> |linux sockets or other| 4. what i try to have | appl | <-> |gnutls with cbs| <-INTER-> |ct lib nb| <-> |linux sockets or other| the problem is that callbacks with blocking behavior complicate unnecessarily my work because 'appl' interacts with 'ct lib nb' on the interface 'INTER' in an asynchronous manner. is there a way to use gnutls to drive tls in the described setup? -- 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 Mon Jan 14 11:26:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 10:26:04 +0000 Subject: [gnutls-devel] GnuTLS | certtool: data encipherment is disabled by default (!875) In-Reply-To: References: Message-ID: Merge Request !875 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/875 Branches: tmp-fix-certtools to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 12:00:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 11:00:36 +0000 Subject: [gnutls-devel] GnuTLS | Improving speed of test suite (#674) References: Message-ID: New Issue was created. Issue 674: https://gitlab.com/gnutls/gnutls/issues/674 Author: Tim R?hsen Assignee: This issue is for discussion on how to improve the speed of the test suite. The following test have been made on a Ryzen 2600 3.4 GHz with `/usr/bin/unbuffer /bin/bash -o pipefail -c "make check -j1"|ts`. **List of slow tests** Name | Duration | Reason --- | --- | --- tls13/key_update|15s dtls-rehandshake-anon|61s|Sleep 60 mini-record|6s record-retvals|5s dtls-rehandshake-cert|61s|Sleep 60 mini-dtls-hello-verify-48|30s rng-sigint|5s rng-op-nonce|8s rng-op-random|8s rng-op-key|8s dtls/dtls|75s starttls-smtp.sh|43s starttls-pop3.sh|41s starttls-sieve.sh|5s ocsp-tests/ocsp-tls-connection|5s ocsp-tests/ocsp-must-staple-connection|14s testpkcs11.sh|9s cert-tests/provable-dh|8s cert-tests/provable-privkey-dsa2048|7s cert-tests/provable-dh-default|5s cert-tests/dsa|5s slow/test-hash-large.sh|38s suite/chain.sh|12s suite/testcompat-openssl.sh|50s suite/testrandom.sh|16s suite/tls-fuzzer/tls-fuzzer-nocert.sh|109s suite/tls-fuzzer/tls-fuzzer-nocert-tls13.sh|127s suite/testcompat-tls13-openssl.sh|39s suite/testdane.sh|15s suite/prime-check|7s Maybe that list helps to separate tests into directories/groups that could by run in parallel on different runners, decreasing the total time of our CI. We could use either configure flags or `make check -C ...` to chose the groups to test. There also might be some tests with optimization potential. At least there are some tests idling / waiting without much CPU consumption. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/674 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 12:06:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 11:06:28 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: This issue is still present in the 3.6.5 release tarball. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_131277232 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 12:50:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 11:50:04 +0000 Subject: [gnutls-devel] GnuTLS | certtool: data encipherment is disabled by default (!875) In-Reply-To: References: Message-ID: Merge Request !875 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/875 Branches: tmp-fix-certtools to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 12:50:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 11:50:13 +0000 Subject: [gnutls-devel] GnuTLS | certtool: data encipherment is disabled by default (!875) 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/875#note_131290551 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 12:50:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 11:50:57 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: Nice catch. Thank you for this. Is there some way we can test these being functional? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_131290721 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 13:04:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 12:04:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add CI tarball build (!809) In-Reply-To: References: Message-ID: d5d62a7d83d558c0ab5b1a4b633655b852ff3c55 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/809#note_131294224 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 13:16:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 12:16:02 +0000 Subject: [gnutls-devel] GnuTLS | Improving speed of test suite (#674) In-Reply-To: References: Message-ID: Note that this is the running in isolation, the contribution to the total running time is not clear from the above since we run the tests in parallel. The parallelization we have already with the `make -j$(nproc)` may be increased further since we have idling processes. We could try '-j' as well. If not, for the `sleep` tests we can improve them by using `virt-sleep.h`. For the `rng-op` tests we have a dedicated issue #669 and by a brief look the test seems to be not tied to the code it is testing, thus we may be able to optimize it. > Maybe that list helps to separate tests into directories/groups that could by run in parallel on different runners More directories reduces parallelization with make. A new runner will add an additional load due to bootstrap/configure and we do not know if a separate machine is used or just another container in the same physical system. Maybe the `nproc` approach will prove more beneficial -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/674#note_131298540 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 16:44:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 15:44:21 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) References: Message-ID: New Issue was created. Issue 675: https://gitlab.com/gnutls/gnutls/issues/675 Author: Nadav Har'El Assignee: On my system (Fedora 28, gnutls-3.6.4-1.fc28.x86_64) the installed gnutls.pc file has the following line: `` Libs.private: -ltspi -lgmp /usr/lib64/libunistring.so -lidn2 `` This shouldn't refer to the full path "/usr/lib64/libunistring.so" - it should be just "-lunistring". So if you're lucky enough to have a static version of all these libraries, static linking (gcc -static) will actually work. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 18:42:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 17:42:12 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: I recommend you take a look at [`gnutls_transport_set_errno()`](https://gnutls.org/manual/gnutls.html#gnutls_005ftransport_005fset_005ferrno). You can implement non-blocking push/pull operation by setting `EAGAIN` or `EINTR` as appropriate and returning `-1`. For example, `mod_gnutls` does this to [implement push/pull in the Apache HTTPD filter chain](https://mod.gnutls.org/browser/mod_gnutls/src/gnutls_io.c#L792). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_131428634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 14 21:11:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 14 Jan 2019 20:11:53 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Are you sure, it's not a custom installed libunistring ? Here (Debian, custom installed libunistring and libidn2) it looks like ``` Libs.private: -lgmp /usr/local/lib/libunistring.so -Wl,-rpath -Wl,/usr/local/lib -lidn2 ``` After uninstalling both libs from /usr/local and a `ldconfig` and `./configure` run in `gnutls/`, the line looks like ``` Libs.private: -lgmp -lunistring -lidn2 ``` Which looks correct. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131512843 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 09:35:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 08:35:09 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: I can verify that this happens in fedora. I see that the detection of libunistring is done by `AC_LIB_HAVE_LINKFLAGS`. It may be something in fedora that makes it decide to link directly with the .so. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131633958 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 09:45:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 08:45:11 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Try it with how libidn2 detects it: ``` if test "$ac_cv_libunistring" = "yes";then AC_SEARCH_LIBS(u8_normalize, unistring, [], [ac_cv_libunistring=no]) fi AM_CONDITIONAL(HAVE_LIBUNISTRING, test "$ac_cv_libunistring" = "yes") ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131636482 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 09:47:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 08:47:47 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: That needs a `unistring_EARLY` after `gl_EARLY` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131637100 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 10:37:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 09:37:32 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Here is an amended/extended `.mailmap` to catch them all. [.mailmap](/uploads/93eede9dc1edb552b8a0a1199cfbd67f/.mailmap) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131660356 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 14:59:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 13:59:30 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Thank you, updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131749528 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 15:05:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 14:05:06 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on .mailmap: > -Nikos Mavrogiannopoulos > -Nikos Mavrogiannopoulos > +Andreas Metzler > +Andreas Metzler > +Daiki Ueno My GNU mailbox is "ueno", not "dueno" ;-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131751323 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 16:44:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 15:44:31 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .mailmap: > -Nikos Mavrogiannopoulos > -Nikos Mavrogiannopoulos > +Andreas Metzler > +Andreas Metzler > +Daiki Ueno corrected! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131786845 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 16:44:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 15:44:40 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: All discussions on Merge Request !872 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/872 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 16:51:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 15:51:01 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Merge Request !872 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/872 Branches: tmp-authors to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 17:23:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 16:23:53 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/872 was reviewed by Tom -- Tom started a new discussion on .mailmap: > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos Is this entry correct? Look the TLD there. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 17:24:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 16:24:31 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Tom started a new discussion on .mailmap: > +Andreas Metzler > +Andreas Metzler > +Daiki Ueno > +Daiki Ueno > +Daiki Ueno > +David Woodhouse > +Giuseppe Scrivano > +Ludovic Court?s > +Ludovic Court?s > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos This one also. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131800314 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 15 18:06:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 15 Jan 2019 17:06:59 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .mailmap: > +Andreas Metzler > +Andreas Metzler > +Daiki Ueno > +Daiki Ueno > +Daiki Ueno > +David Woodhouse > +Giuseppe Scrivano > +Ludovic Court?s > +Ludovic Court?s > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos > +Nikos Mavrogiannopoulos Unfortunately they are "correct". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_131815693 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 09:29:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 08:29:44 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Just tested on our fedora29 docker image (fresh local build) and I can't reproduce: ``` # cat lib/gnutls.pc # Process this file with autoconf to produce a pkg-config metadata file. # Copyright (C) 2004-2012 Free Software Foundation, Inc. # Copying and distribution of this file, with or without modification, # are permitted in any medium without royalty provided the copyright # notice and this notice are preserved. This file is offered as-is, # without any warranty. # Author: Simon Josefsson prefix=/usr/local exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: GnuTLS Description: Transport Security Layer implementation for the GNU system URL: http://www.gnutls.org/ Version: 3.6.5 Libs: -L${libdir} -lgnutls Libs.private: -ltspi -lgmp -lunistring -lidn2 Requires.private: nettle, hogweed, libtasn1, p11-kit-1 Cflags: -I${includedir} ``` So looks like Fedora meanwhile fixed it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131968221 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 09:45:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 08:45:25 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Also not reproducible with out Fedora28 docker image (gnutls.pc looks the same as above). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_131973391 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 11:28:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 10:28:04 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: thank you for your reply. i was already doing this but without [gnutls_transport_set_errno()](https://gnutls.org/manual/gnutls.html#gnutls_005ftransport_005fset_005ferrno) function. unfortunately this produces infinite loop until manual intervention. the problem is that my environment is single threaded therefore client thread is blocked in `waiting to receive` and cannot really let my custom transport send the issued handshake. after handshake is generated in the client both, client and server processes are `waiting to receive` thus blocking the whole program. i will edit my first post to reflect the threading model in my environment. ``` 20664: rcvd server -> handshake ... 20664: server level 5 REC[0x7efd500023a0]: Allocating epoch #1 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client gnutls -> handshake ... 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 5 REC[0x7f47c80024d0]: Allocating epoch #1 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 HSK[0x7f47c80024d0]: Adv. version: 3.3 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 2 Keeping ciphersuite cc.ac (GNUTLS_ECDHE_PSK_CHACHA20_POLY1305) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 2 Keeping ciphersuite 00.ab (GNUTLS_DHE_PSK_AES_256_GCM_SHA384) 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 2 Keeping ciphersuite cc.ad (GNUTLS_DHE_PSK_CHACHA20_POLY1305) 20653: client level 2 Keeping ciphersuite c0.a7 (GNUTLS_DHE_PSK_AES_256_CCM) 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 2 Keeping ciphersuite 00.a9 (GNUTLS_PSK_AES_256_GCM_SHA384) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 2 Keeping ciphersuite cc.ab (GNUTLS_PSK_CHACHA20_POLY1305) 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 2 Keeping ciphersuite c0.a5 (GNUTLS_PSK_AES_256_CCM) 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Maximum Record Size/1) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (OCSP Status Request/5) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Client Certificate Type/19) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Server Certificate Type/20) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Supported Groups/10) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Sent group SECP384R1 (0x18) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Sent group SECP521R1 (0x19) 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Sent group FFDHE8192 (0x104) 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Supported Groups/10 (8 bytes) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Supported EC Point Formats/11) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Supported EC Point Formats/11 (2 bytes) 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (SRP/12) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Signature Algorithms/13) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (5.1) RSA-SHA384 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (8.10) RSA-PSS-SHA384 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (8.5) RSA-PSS-RSAE-SHA384 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (5.3) ECDSA-SHA384 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (6.1) RSA-SHA512 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (8.11) RSA-PSS-SHA512 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (8.6) RSA-PSS-RSAE-SHA512 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: sent signature algo (6.3) ECDSA-SHA512 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Signature Algorithms/13 (18 bytes) 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (SRTP/14) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Heartbeat/15) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (ALPN/16) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Encrypt-then-MAC/22) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Encrypt-then-MAC/22 (0 bytes) 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Extended Master Secret/23) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Extended Master Secret/23 (0 bytes) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Session Ticket/35) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Key Share/51) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Supported Versions/43) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Post Handshake Auth/49) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Safe Renegotiation/65281) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Safe Renegotiation/65281 (1 bytes) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Server Name Indication/0) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Cookie/44) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Early Data/42) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (PSK Key Exchange Modes/45) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Record Size Limit/28) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 EXT[0x7f47c80024d0]: Sending extension Record Size Limit/28 (2 bytes) 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (ClientHello Padding/21) for 'client hello' 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 4 EXT[0x7f47c80024d0]: Preparing extension (Pre Shared Key/41) for 'client hello' 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 4 HSK[0x7f47c80024d0]: CLIENT HELLO was queued [118 bytes] 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 11 HWRITE: enqueued [CLIENT HELLO] 118. Total 118 bytes. 20653: client level 11 HWRITE FLUSH: 118 bytes in buffer. 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 5 REC[0x7f47c80024d0]: Preparing Packet Handshake(22) with length: 118 and min pad: 0 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 9 ENC[0x7f47c80024d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 11 WRITE: enqueued 123 bytes for 0x7f47e402c990. Total 123 bytes. 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 5 REC[0x7f47c80024d0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 123 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 11 HWRITE: wrote 1 bytes, 0 bytes left. 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 11 WRITE FLUSH: 123 bytes in buffer. 20653: client sending 123 bytes ... 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client sent 123 bytes 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 11 WRITE: wrote 123 bytes, 0 bytes left. 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20653: client level 10 READ: -1 returned from 0x7f47e402c990, errno=115 gerrno=11 20664: server level 10 READ: -1 returned from 0x7efd6c02c990, errno=11 gerrno=11 20653: client level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20664: server level 3 ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:589 20653: client level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 20664: server level 3 ASSERT: ../../lib/buffers.c[get_last_packet]:1171 ... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_132011526 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 15:03:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 14:03:54 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: I just checked on Fedora 29 too, latest "gnutls-devel" package, and see in /usr/lib64/pkgconfig/gnutls.pc: ``` Libs.private: -ltspi -lgmp /usr/lib64/libunistring.so -lidn2 ``` So I don't know you guys see something different. Very strange... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132084615 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 15:38:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 14:38:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: OK, then it's a packaging issue at Fedora and it must be fixed there. What I did is building the latest GnuTLS from git (on Fedore28 / Fedora29) to see if there is a fundamental issue with either GnuTLS's build system or with the development packages provided by Fedora. It isn't. @nmav Did you open an issue at Fedora ? We could then close this one here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132097313 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 16:18:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 15:18:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Tim R?hsen @rockdaboot commented 38 minutes ago > OK, then it's a packaging issue at Fedora and it must be fixed there. It is not Fedora specific, it also shows up on Debian. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132112261 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 16:19:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 15:19:37 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) References: Message-ID: New Issue was created. Issue 676: https://gitlab.com/gnutls/gnutls/issues/676 Author: Hubert Kario Assignee: ## Description of problem: There are multiple issues related to handling of the record_size_limit extension, but since there's just one reproducer script, I'm filing a single bug. ### Individual issues 1. record_size_limit extension does not influence renegotiation handshake records or is applied right-away after receiving the new ClientHello, while RFC states "Records are subject to the limits that were set in the handshake that produces the keys that are used to protect those records." this causes `renegotiation with dropped extension` and `renegotiation with changed limit` to fail with record_overflow 1. gnutls sends smaller than possible value in TLS 1.3 - the limit in TLS 1.3 is 2**14 + 1. This causes `HRR sanity`, `change size in TLS 1.3 session resumption`, `check if server accepts maximum size in TLS 1.3`, `too large record payload in TLS 1.3`, `check server sent size in TLS 1.3`, `drop extension in TLS 1.3 session resumption` to fail 1. a modified extension in 2nd CH in HRR handshake is not detected and handshake is not aborted. Test case `modified extension in 2nd CH in HRR handshake`. 1. malformed extension, with bigger payload than specified is not rejected. This causes `padded extension in TLS 1.3` and `padded extension in TLS 1.2` to fail 1. when extension is negotiated, the 1/n-1 record splitting in TLS 1.0 is disabled, this causes `check if server accepts maximum size in TLS 1.0` and `check server sent size in TLS 1.0` to fail 1. Too large application_data records in TLS 1.2 are not detected when the extension is negotiated. This causes `too large record in TLS 1.2` to fail 1. GnuTLS does not advertise the extension during session resumption. This causes `change size in TLS 1.2 resumption` to fail 1. the server sends too large records when minimal size is advertised by client (ignores the extension?!). This causes `check if server accepts minimal size in TLS 1.2`, `check if server accepts minimal size in TLS 1.1` and `check if server accepts minimal size in TLS 1.0` to fail ## Version of gnutls used: b527be10f829e ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) local compile on Fedora 28 ## How reproducible: chekout https://github.com/tomato42/tlsfuzzer/pull/494 run `test-record-size-limit.py --reply-AD-size 821` ## Actual results: ``` Test end successful: 12 failed: 21 'change size in TLS 1.2 resumption' 'change size in TLS 1.3 session resumption' 'check if server accepts maximum size in TLS 1.0' 'check if server accepts maximum size in TLS 1.3' 'check if server accepts minimal size in TLS 1.0' 'check if server accepts minimal size in TLS 1.1' 'check if server accepts minimal size in TLS 1.2' 'check if server accepts minimal size in TLS 1.3' 'check interaction with sha256 prf' 'check interaction with sha384 prf' 'check server sent size in TLS 1.0' 'check server sent size in TLS 1.3' 'drop extension in TLS 1.3 session resumption' 'HRR sanity' 'modified extension in 2nd CH in HRR handshake' 'padded extension in TLS 1.2' 'padded extension in TLS 1.3' 'renegotiation with changed limit' 'renegotiation with dropped extension' 'too large record in TLS 1.2' 'too large record payload in TLS 1.3' ``` ## Expected results: ``` successful: 33 failed: 0 ``` -- 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 Wed Jan 16 16:27:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 15:27:23 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 (Dec 1, 2018?Jan 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- 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 Wed Jan 16 16:55:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 15:55:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: > It is not Fedora specific, it also shows up on Debian. I work on Debian unstable and can't reproduce, but can see that you are right. Anyways, building GnuTLS (from git) on Debian unstable and `make install` results in ``` $ cat /usr/local/lib/pkgconfig/gnutls.pc ... Libs.private: -ltspi -lgmp -lunistring -lidn2 ... ``` Isn't that what Debian package building basically does (make install + then collect the data) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132126091 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 17:31:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 16:31:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Tim R?hsen @rockdaboot commented 29 minutes ago > Isn't that what Debian package building basically does (make install + then collect the data) ? Yes. The significant difference to your build is that Debian is using multiarch, i.e. we set --libdir. e.g. on amd64 the following command sequence will reproduce the issue: `mkdir b4deb ; cd b4deb ; ../configure --without-tpm --disable-guile --disable-rpath --enable-libdane --prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu && make -j5` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132138717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 18:06:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 17:06:36 +0000 Subject: [gnutls-devel] GnuTLS | fastopen: only use connectx if available (!876) References: Message-ID: New Merge Request !876 https://gitlab.com/gnutls/gnutls/merge_requests/876 Project:Branches: AmarOk1412/gnutls:fix/connectx to gnutls/gnutls:master Author: S?bastien Blin 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 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/876 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 16 18:07:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 16 Jan 2019 17:07:29 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: This seems to work: https://gitlab.com/gnutls/gnutls/merge_requests/876/diffs -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662#note_132150892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 09:34:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 08:34:29 +0000 Subject: [gnutls-devel] GnuTLS | fastopen: only use connectx if available (!876) In-Reply-To: References: Message-ID: It looks like you took code from the curl project. They have a different license and the code seems to be wrong (copy&paste issue). Why not simply adding `connectx` to `AC_CHECK_FUNCS` ? And why not simply changing the definition of `TCP_FASTOPEN_OSX` in lib/system/fastopen.c ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/876#note_132315932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 10:26:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 09:26:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) References: Message-ID: New Merge Request !877 https://gitlab.com/gnutls/gnutls/merge_requests/877 Branches: tmp-fix-libs-private 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 #675 ## 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/877 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 10:29:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 09:29:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Thanks @ametzler ! That makes it reproducible. I changed the libunistring detection in !877 to fix it. Please review / test. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675#note_132334956 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 10:46:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 09:46:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: I will try to create a reproducer, although I don't know yet how to emulate the FIPS mode as being set. At least I can write a reproducer which provides HMAC files with and without newlines which should result in a successful integrity check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_132342766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 11:04:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 10:04:21 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Could you please rebase it w/o AUTHORS commit? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_132351330 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 11:23:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 10:23:57 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: @lumag Ups, sorry. Rebased. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_132358368 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 12:32:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 11:32:02 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Why not also add translators ? `echo -e "\nTranslators:"; sed -n 's/.*Last-Translator: *\(.*\) *<.*/\1/p' po/*.po | sort -u` BTW, do you inform the translation project from time to time, give them a link to a recent tarball ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_132380816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 13:27:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 12:27:29 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) References: Message-ID: New Merge Request !878 https://gitlab.com/gnutls/gnutls/merge_requests/878 Project:Branches: ffontaine/gnutls:master to gnutls/gnutls:master Author: Fabrice Fontaine Assignee: gnutls source code uses the C++11 atomic functionality since https://github.com/gnutls/gnutls/commit/7978a733460f92b31033affd0e487c86d66c643d, which internally is implemented using the __atomic_*() gcc built-ins On certain architectures, the `__atomic_*()` built-ins are implemented in the libatomic library that comes with the rest of the gcc runtime. Due to this, code using might need to link against libatomic, otherwise one hits build issues such as: ../lib/.libs/libgnutls.so: undefined reference to `__atomic_fetch_sub_4' on an architecture like SPARC. To solve this, a configure.ac check is added to know if we need to link against libatomic or not. The library is also added to gnutls.pc. Fixes: - http://autobuild.buildroot.org/results/6c749bd592ceffeacadd2ab570d127936cce64b2 - http://autobuild.buildroot.org/results/30aa83d3cf3482af8a59250c196c85f4a278d343 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 15:21:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 14:21:10 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Merge Request !877 was approved by Andreas Metzler Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/877 Branches: tmp-fix-libs-private to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 15:21:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 14:21:27 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Looks good, thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_132441228 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 16:14:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 15:14:52 +0000 Subject: [gnutls-devel] GnuTLS | fastopen: only use connectx if available (!876) In-Reply-To: References: Message-ID: > It looks like you took code from the curl project. Yup I am really sorry about that. I did that only to fix my pipeline at first and the check is correct in the curl project. > Why not simply adding `connectx` to `AC_CHECK_FUNCS` ? It's not enough. This was the first patch I tried. `connectx` is detected, but not usable due to the `--no-weak-import` flag. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/876#note_132459332 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 16:33:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 15:33:14 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Fix issues in record_size_limit extension handling (!879) References: Message-ID: New Merge Request !879 https://gitlab.com/gnutls/gnutls/merge_requests/879 Branches: tmp-fix-record-size-limit-resumption to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This fixes (some of) the issues discovered in #676, namely: - reset the negotiated limit upon resumption - reject over-long extension value - abort connection if the requested value is smaller than our lower limit - make the uses of max_record_{send,recv}_size consistent with the comment ## 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/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 Jan 17 16:50:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 15:50:16 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: I have filed !879 that should fix some of the issues. For 2, GnuTLS uses 2**14 as the upper limit, regardless of the version. If we want 2**14+1 for TLS 1.3, it would require delaying the initialization after version negotiation. I'm not sure if such complexity is worth it just for 1 byte. Similarly for 8, the lower limit is 512 and adding support for [64, 511) doesn't look straightforward. For 5, does the 1/n-1 splitting in TLS 1.0 actually work without the extension? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132471795 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 17 20:15:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 17 Jan 2019 19:15:55 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: > Similarly for 8, the lower limit is 512 and adding support for [64, 511) doesn't look straightforward. After digging it further, I realized that it's merely failing in `_gnutls_io_write_flush()` while queuing. So I guess we could either bump the limit of the maximum size of the queue, dynamically allocate it, or make sure that the caller of the function calls it multiple times taking into account of the maximum. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132531604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 10:48:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 09:48:24 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: Fragmentation on the [64,511) range may be used for denial of service attacks and in practice we have no systems requiring such small fragmentation. Unless we have a very compelling use my recommendation would be to keep 512 as minimum negotiated size. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132678684 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 10:50:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 09:50:58 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: It may make sense to split this issue to two, based on the things that we should address and things which look nice to have. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132679440 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 10:52:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 09:52:21 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: In `.gitlab-ci.yml` there is a FIPS build which enables FIPS mode using environment variables. One of them explicitly disables HMAC testing. What do you think of having a single test that runs with hmac tests enabled? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_132679826 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 13:11:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 12:11:01 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: It seems a good way, I'll try. Thanks for the suggestion! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_132723280 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 14:04:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 13:04:35 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: the thing is that 64 is the explicit lower limit established in the RFC, so it's hard to claim compliance if that value will not be respected by GnuTLS if it is advertised by the other side > If we want `2**14+1` for TLS 1.3, it would require delaying the initialization after version negotiation. but version negotiation should be the very first thing that you do, and anyway, in TLS 1.3 the limit applies only after ServerHello was prepared and encryption keys calculated, at that point you must know what version is negotiated > For 5, does the 1/n-1 splitting in TLS 1.0 actually work without the extension? I don't know, haven't checked it for some time, but there are tests that expect split ApplicationData in TLS 1.0 and earlier, e.g. `test-serverhello-random.py` (though they don't verify that the first appdata is exactly 1 byte long as that feature was added in the above quoted PR...) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132738626 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 18 14:53:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 18 Jan 2019 13:53:30 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: > the thing is that 64 is the explicit lower limit established in the RFC, so it's hard to claim compliance if that value will not be respected by GnuTLS if it is advertised by the other side @nmav pointed that the RFC suggests: > Endpoints SHOULD advertise the "record_size_limit" extension, even if they have no need to limit the size of records. [...] *For servers, this allows clients to know that their limit will be respected.* Conversely, if the server doesn't want to respect the limit the client advertised, couldn't it indicate that by omitting "record_size_limit" in SH or EE? I am not sure if the sentence is only about the upper limit though. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_132767163 You're receiving 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 Jan 19 07:37:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 06:37:38 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Updated; yes, now and then -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872#note_132981128 You're receiving 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 Jan 19 10:48:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 09:48:15 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: I have the same issue on my system (guile-2.2 only) and tracked it down to an old 'guile.m4' that is pulled in during autoconf. Changing the line ` _guile_versions_to_search="m4_default([$1], [2.2 2.0 1.8])"` and recreating the build system files fixes the issue for me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_132990812 You're receiving 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 Jan 19 16:09:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 15:09:53 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: All discussions on Merge Request !872 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/872 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872 You're receiving 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 Jan 19 16:10:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 15:10:28 +0000 Subject: [gnutls-devel] GnuTLS | auto-generate the AUTHORS file (!872) In-Reply-To: References: Message-ID: Merge Request !872 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/872 Branches: tmp-authors to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/872 You're receiving 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 Jan 19 18:07:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 17:07:00 +0000 Subject: [gnutls-devel] GnuTLS | crypto-selftests.c: Fix checking return value (!880) References: Message-ID: New Merge Request !880 https://gitlab.com/gnutls/gnutls/merge_requests/880 Branches: tmp-fix-crypto-selftests 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 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/880 You're receiving 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 Jan 19 18:14:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 17:14:58 +0000 Subject: [gnutls-devel] GnuTLS | Fix timeout in gnutls_idna_parser_fuzzer (!881) References: Message-ID: New Merge Request !881 https://gitlab.com/gnutls/gnutls/merge_requests/881 Branches: tmp-fix-fuzzer-timeout 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 Libidn2 has a O(N^2) behavior in idn2_to_ascii_8z(). It is fast enough for real world domains, so a limit of 1024 for fuzzer corpora seems to be fine. The reproducer for 25s timeout had a data size of 610k. ## 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/881 You're receiving 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 Jan 19 18:22:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 17:22:17 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized variable in tests/x509dn.c (!882) References: Message-ID: New Merge Request !882 https://gitlab.com/gnutls/gnutls/merge_requests/882 Branches: tmp-init-var-x509dn 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 There was a `goto end` before `session` was initialized. ## 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/882 You're receiving 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 Jan 19 20:18:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:18:16 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized variable in tests/x509dn.c (!882) In-Reply-To: References: Message-ID: Merge Request !882 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/882 Branches: tmp-init-var-x509dn to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/882 You're receiving 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 Jan 19 20:18:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:18:44 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized variable in tests/x509dn.c (!882) In-Reply-To: References: Message-ID: Verified that `gnutls_deinit()` explicitly handles the `NULL` case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/882#note_133028632 You're receiving 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 Jan 19 20:19:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:19:00 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized variable in tests/x509dn.c (!882) In-Reply-To: References: Message-ID: Merge Request !882 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/882 Branches: tmp-init-var-x509dn to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/882 You're receiving 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 Jan 19 20:22:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:22:53 +0000 Subject: [gnutls-devel] GnuTLS | Fix timeout in gnutls_idna_parser_fuzzer (!881) In-Reply-To: References: Message-ID: Shouldn't we put the limit in `gnutls_idna_map()` so that we protect the library for such cases as well? Is there an upper limit in UTF-8 domain names? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881#note_133028834 You're receiving 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 Jan 19 20:23:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:23:17 +0000 Subject: [gnutls-devel] GnuTLS | crypto-selftests.c: Fix checking return value (!880) In-Reply-To: References: Message-ID: Merge Request !880 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/880 Branches: tmp-fix-crypto-selftests to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/880 You're receiving 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 Jan 19 20:23:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:23:24 +0000 Subject: [gnutls-devel] GnuTLS | crypto-selftests.c: Fix checking return value (!880) In-Reply-To: References: Message-ID: LGTM! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/880#note_133028864 You're receiving 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 Jan 19 20:25:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:25:55 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: LGTM. Run took 47 seconds. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133028997 You're receiving 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 Jan 19 20:26:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:26:00 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: Merge Request !874 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/874 Branches: tmp-check-if-signed to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874 You're receiving 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 Jan 19 20:29:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:29:22 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: I haven't however test it for functionality. It uses `git log` since last merge(?) to see if signoff is missing. Not sure if it would be more simple, reliable or less if we use gitlab's variables: https://docs.gitlab.com/ee/ci/variables/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133029177 You're receiving 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 Jan 19 20:42:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:42:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix timeout in gnutls_idna_parser_fuzzer (!881) In-Reply-To: References: Message-ID: In general, I am against putting such limits into a library function (maybe someone wants to wait hours or days for a result). But in this case someone could possibly use it as a DOS attack. - We have to investigate the code in libidn2 (I did a while ago, but don't remember the results). - The ASCII / punycode form of a domain is limited to 253 characters. Better: the limit is due to DNS constraints. There are ASCII representations that are shorter than their UCS4 representation in terms of characters, but I don't know the corner cases / limits. The UTF-8 representation could be up to 4x longer (in terms of bytes). Put another 2x and you have a nice limit of 2048 chars for the input. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881#note_133029868 You're receiving 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 Jan 19 20:46:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:46:09 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: It uses `git log` for the deviation since master. That is/are exactly the new commits in a MR - and exactly what we want to test. I don't like relying on Gitlab variables here (whatever they do). It a general script perfectly working outside of Gitlab. Why limiting it ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133030040 You're receiving 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 Jan 19 20:46:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:46:44 +0000 Subject: [gnutls-devel] GnuTLS | crypto-selftests.c: Fix checking return value (!880) In-Reply-To: References: Message-ID: Merge Request !880 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/880 Branches: tmp-fix-crypto-selftests to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/880 You're receiving 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 Jan 19 20:54:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 19:54:10 +0000 Subject: [gnutls-devel] GnuTLS | Fix timeout in gnutls_idna_parser_fuzzer (!881) In-Reply-To: References: Message-ID: Ah, the underlying `_idn2_punycode_encode()` is O(N^2). I once tried to rewrite it to O(N), but never finished it. Maybe it's not possible in the end (have to review the algorithm again). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881#note_133030380 You're receiving 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 Jan 19 22:05:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 21:05:00 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: Gitlab has few options for its CI to pull changes (fetch etc). I do not know whether git log would work consistently. I know that tags for example are not available on builders. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133033685 You're receiving 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 Jan 19 22:35:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 19 Jan 2019 21:35:20 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: Tags doesn't matter. And I have to correct myself to "It uses git log for the deviation from the originating branch". That means it also checks the commits of a MR even when the parent branch isn't master. I'd say, let's try it. If it ever fails, we can revert/amend. But I couldn't make it fail so far. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133035195 You're receiving 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 Jan 20 11:37:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 20 Jan 2019 10:37:23 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: If you believe it is ok, it is fine with me -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874#note_133066362 You're receiving 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 Jan 20 11:49:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 20 Jan 2019 10:49:45 +0000 Subject: [gnutls-devel] GnuTLS | Fix timeout in gnutls_idna_parser_fuzzer (!881) In-Reply-To: References: Message-ID: @nmav I just pushed a fix to libidn2. Let's see how it works out on oss-fuzz in the next days. Anyways, we should use an arbitrary "large enough" limit in `gnutls_idna_map()`. The exact calculation is complicated and can only be done in libidn2. So 2048 as input size limit is perfectly fine for `gnutls_idna_map()`. I'll change this MR respectively. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881#note_133067008 You're receiving 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 Jan 20 14:34:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 20 Jan 2019 13:34:16 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by: in CI (!874) In-Reply-To: References: Message-ID: Merge Request !874 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/874 Branches: tmp-check-if-signed to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/874 You're receiving 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 Jan 20 14:34:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 20 Jan 2019 13:34:15 +0000 Subject: [gnutls-devel] GnuTLS | Check for Signed-off-by in CI (#668) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #668: https://gitlab.com/gnutls/gnutls/issues/668 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/668 You're receiving 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 Jan 20 17:10:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 20 Jan 2019 16:10:29 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) References: Message-ID: New Issue was created. Issue 677: https://gitlab.com/gnutls/gnutls/issues/677 Author: Alfred Feldmeyer Assignee: ## Description of problem: After I upgraded Fedora 29 I am not able to connect to anyconnect VPN any more. The error is: > SSL connection failure: A TLS fatal alert has been received. After further investigation I installed gnutls 3.5.18 from source and did a test via ``` gnutls-cli -V -p 443 vpn.gateway.url --debug=2 ```
Success with version 3.8.15 

Processed 156 CA certificate(s).
Resolving 'vpn.gateway.url:443'...
Connecting to '123.123.123.123:443'...
|<2>| HSK[0xddd6e0]: sent server name: 'vpn.gateway.url'
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 18a8ff230001000017a5
	Issuer: CN=COMPANY Issuing CA,OU=IT,O=COMPANY,C=DE
	Validity:
		Not Before: Wed Sep 20 07:56:36 UTC 2017
		Not After: Fri Sep 20 08:06:36 UTC 2019
	Subject: CN=vpn.gateway.url,1.2.840.113549.1.9.2=#131166772d6d75632d30312e6d7765612e6465
	Subject Public Key Algorithm: RSA
	Algorithm Security Level: Medium (2048 bits)
		Modulus (bits 2048):
			00:a9:[stripped for sec reasons]:0a:a8
			0f
		Exponent (bits 24):
			01:00:01
	Extensions:
		Key Usage (critical):
			Digital signature.
			Key encipherment.
		Subject Alternative Name (not critical):
			DNSname: vpn.gateway.url
			DNSname: ...
			DNSname: ...
		Subject Key Identifier (not critical):
			01cd57c534e1189f9b3153c85a4fa12dff375ed4
		Authority Key Identifier (not critical):
			4ac2d8fb3959d083555f0579f1f1bf4541b2ce4c
		CRL Distribution points (not critical):
			URI: ldap:///CN=Company,CN=CERT-HQ-02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Company,DC=de?certificateRevocationList?base?objectClass=cRLDistributionPoint
			URI: http://ca.company.de/cert.crl
		Authority Information Access (not critical):
			Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)
			Access Location URI: ldap:///CN=Company%20Issuing%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Company,DC=de?cACertificate?base?objectClass=certificationAuthority
			Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)
			Access Location URI: http://ca.Company.de/cert.crt
		Unknown extension 1.3.6.1.4.1.311.21.7 (not critical):
			ASCII: 0..&+.....7.....(...Q...........v........k..d...
			Hexdump: 302e06262b060104018237150886c7fe288195915186d99b0484d2c81f82ff87761287eb901084f0f96b020164020103
		Key Purpose (not critical):
			TLS WWW Server.
		Unknown extension 1.3.6.1.4.1.311.21.10 (not critical):
			ASCII: 0.0...+.......
			Hexdump: 300c300a06082b06010505070301
	Signature Algorithm: RSA-SHA256
	Signature:
		8d:2b:[stripped for sec reasons]:59:0e
Other Information:
	Fingerprint:
		sha1:623479822c783d2bda8f1d4074e15711ad3eb860
		sha256:535ec4065ec807977c40334570280165de7957ac29ddc7197ead9e55110ec565
	Public Key ID:
		sha1:d7261b3e3fc8cc08479a3f3243c39d66b340fe38
		sha256:c1b2249cdc672832c56b099a6a1c11a59cfdf2500f112334c3dda20d8d77d8d3
	Public Key PIN:
		pin-sha256:wbIknNxnKDLFawmaahwRpZz98lAPESM0w92iDY132NM=
	Public key's random art:
		+--[ RSA 2048]----+
		|                 |
		|                 |
		|                 |
		|      . .  .     |
		|     + =S.+ o    |
		|      X Bo =     |
		|     . @ B+.     |
		|      E * =o.    |
		|       = .  ..   |
		+-----------------+


-----BEGIN CERTIFICATE-----
[stripped for sec reasons]
-----END CERTIFICATE-----

- Certificate[1] info:
 - X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 6131b673000100000006
	Issuer: CN=Company Root CA,OU=IT,O=Company,C=DE
	Validity:
		Not Before: Tue Jan 31 14:50:55 UTC 2017
		Not After: Sun Jan 31 15:00:55 UTC 2027
	Subject: CN=Company Issuing CA,OU=IT,O=Company,C=DE
	Subject Public Key Algorithm: RSA
	Algorithm Security Level: Medium (2048 bits)
		Modulus (bits 2048):
			00:b9:[stripped for sec reasons]:a4:98:5d
			07
		Exponent (bits 24):
			01:00:01
	Extensions:
		Unknown extension 1.3.6.1.4.1.311.21.1 (not critical):
			ASCII: .....
			Hexdump: 0203010001
		Unknown extension 1.3.6.1.4.1.311.21.2 (not critical):
			ASCII: ..?.m.*...o.bH.8m.....
			Hexdump: 04143fb56dde2af40a886fd96248c8386dc32e13beb9
		Subject Key Identifier (not critical):
			4ac2d8fb3959d083555f0579f1f1bf4541b2ce4c
		Unknown extension 1.3.6.1.4.1.311.20.2 (not critical):
			ASCII: ...S.u.b.C.A
			Hexdump: 1e0a00530075006200430041
		Key Usage (not critical):
			Digital signature.
			Certificate signing.
			CRL signing.
		Basic Constraints (critical):
			Certificate Authority (CA): TRUE
		Authority Key Identifier (not critical):
			231242231296a321184327fea42e6c9744bd2acd
		CRL Distribution points (not critical):
			URI: http://ca.Company.de/cert.crl
		Authority Information Access (not critical):
			Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)
			Access Location URI: http://ca.Company.de/cert.crt
	Signature Algorithm: RSA-SHA256
	Signature:
		1b:da:[stripped for sec reasons]:f5:58
Other Information:
	Fingerprint:
		sha1:...
		sha256:...
	Public Key ID:
		sha1:...
		sha256:...
	Public Key PIN:
		pin-sha256:...
	Public key's random art:
		+--[ RSA 2048]----+
		|                 |
		|                 |
		|      . .        |
		|     . o .       |
		|      o S   . . .|
		|       .    .+.o+|
		|        .. o..+*o|
		|       ...+ .=.o*|
		|      ..+=..o.oE=|
		+-----------------+


-----BEGIN CERTIFICATE-----
[stripped for sec reasons]
-----END CERTIFICATE-----

- Certificate[2] info:
 - X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 65c4668ec11c90b94561d2c7a8304140
	Issuer: CN=Company Root CA,OU=IT,O=Company,C=DE
	Validity:
		Not Before: Tue Jan 31 12:33:52 UTC 2017
		Not After: Sat Jan 31 12:43:52 UTC 2032
	Subject: CN=Company Root CA,OU=IT,O=Company,C=DE
	Subject Public Key Algorithm: RSA
	Algorithm Security Level: High (4096 bits)
		Modulus (bits 4096):
			00:b8:e1:2e:[stripped for sec reasons]:70:fe
			c7
		Exponent (bits 24):
			01:00:01
	Extensions:
		Key Usage (not critical):
			Digital signature.
			Certificate signing.
			CRL signing.
		Basic Constraints (critical):
			Certificate Authority (CA): TRUE
		Subject Key Identifier (not critical):
			231242231296a321184327fea42e6c9744bd2acd
		Unknown extension 1.3.6.1.4.1.311.21.1 (not critical):
			ASCII: .....
			Hexdump: 0203010001
		Unknown extension 1.3.6.1.4.1.311.21.2 (not critical):
			ASCII: ......F.|7E.*...&..)mi
			Hexdump: 0414819414f746907c3745bd2aa5cc9226eefb296d69
	Signature Algorithm: RSA-SHA256
	Signature:
		10:04:[stripped for sec reasons]:68:3e
Other Information:
	Fingerprint:
		sha1:...
		sha256:...
	Public Key ID:
		sha1:...
		sha256:...
	Public Key PIN:
		pin-sha256:...
	Public key's random art:
		+--[ RSA 4096]----+
		|      o+o        |
		|     =Eo..       |
		|    . B o .      |
		|     o = +       |
		|      . S +      |
		|       * + .     |
		|      o . o .    |
		|       .o +o     |
		|       oo*oo.    |
		+-----------------+


-----BEGIN CERTIFICATE-----
[stripped for sec reasons]
-----END CERTIFICATE-----

- Status: The certificate is trusted. 
- Description: (TLS1.2)-(RSA)-(AES-256-CBC)-(SHA256)
- Session ID: 40:09:5D:29:44:EF:64:E2:F0:71:31:30:53:59:97:E3:21:56:AB:50:AA:04:08:29:EB:08:EB:01:8A:F0:FF:47
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-256-CBC
- MAC: SHA256
- Compression: NULL
- Options: safe renegotiation,
- Channel binding 'tls-unique': dc551fc134a28bbffc427b0f
- Handshake was completed

- Simple Client Mode:
Handshake fails with version 3.6.5 

|<2>| Initializing needed PKCS #11 modules
|<2>| p11: Initializing module: p11-kit-trust
|<2>| p11: No login requested.
|<2>| p11: No login requested.
Processed 186 CA certificate(s).
Resolving 'vpn.gateway.url'...
Connecting to '123.123.123.123:443'...
|<2>| system priority /etc/crypto-policies/back-ends/gnutls.config has not changed
|<2>| resolved 'SYSTEM' to 'NONE:+MAC-ALL:-MD5:+GROUP-ALL:+SIGN-ALL:-SIGN-RSA-MD5:-SIGN-DSA-SHA1:-SIGN-DSA-SHA224:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-SIGN-DSA-SHA512:+SIGN-RSA-SHA1:%VERIFY_ALLOW_SIGN_WITH_SHA1:+CIPHER-ALL:-CAMELLIA-256-GCM:-CAMELLIA-128-GCM:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-3DES-CBC:-ARCFOUR-128:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA:+VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:+COMP-NULL:%PROFILE_LOW', next ''
|<2>| selected priority string: NONE:+MAC-ALL:-MD5:+GROUP-ALL:+SIGN-ALL:-SIGN-RSA-MD5:-SIGN-DSA-SHA1:-SIGN-DSA-SHA224:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-SIGN-DSA-SHA512:+SIGN-RSA-SHA1:%VERIFY_ALLOW_SIGN_WITH_SHA1:+CIPHER-ALL:-CAMELLIA-256-GCM:-CAMELLIA-128-GCM:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-3DES-CBC:-ARCFOUR-128:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA:+VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:+COMP-NULL:%PROFILE_LOW
|<2>| added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list
|<2>| Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256)
|<2>| Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256)
|<2>| Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM)
|<2>| Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM)
|<2>| Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1)
|<2>| Advertizing version 3.4
|<2>| Advertizing version 3.3
|<2>| Advertizing version 3.2
|<2>| Advertizing version 3.1
|<2>| HSK[0x564ec2cf90b0]: sent server name: 'vpn.gateway.url'
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
## Version of gnutls used: 3.6.5 -> fails 3.5.18 -> success (but outdated in Fedora repos) ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora 29 ## How reproducible: Steps to Reproduce: * find an anyconnect vpn gateway v 4.6 that uses certs to user auth. * run the above commands ## Actual results: Handshake does not work ## Expected results: Handshake does works I am aware, that this seems to be a tricky one, so if you need anything from my side -> let me know Thanks in advance -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 08:13:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 07:13:39 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Most likely this is addressed by: https://gitlab.com/gnutls/gnutls/merge_requests/868 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_133207818 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 08:13:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 07:13:50 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 (Dec 1, 2018?Jan 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 08:15:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 07:15:32 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: @rockdaboot how should we address this? should we revert to the old vasprintf and remove the gnulib one? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133208132 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 10:21:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 09:21:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Could you please open an MR for that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133241912 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 11:29:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 10:29:04 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: @nmav I don't think that's something we can fix in a MR. As described in https://gitlab.com/gnutls/gnutls/issues/631#note_120995932 the build system needs guile 2.2. On your host system, where you create the tarball you need: ``` $ grep "_guile_versions_to_search" /usr/share/aclocal/guile.m4 _guile_versions_to_search="m4_default([$1], [2.2 2.0 1.8])" ``` @sbirkholz So this is a problem of your operating system. On my openSUSE Tumbleweed I have guile-2.2 and the correct guile.m4 file. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133267181 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 13:07:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 12:07:14 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) References: Message-ID: New Merge Request !883 https://gitlab.com/gnutls/gnutls/merge_requests/883 Branches: tmp-fetch-fuzz-corpora-faster 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 Download OSS-Fuzz fuzzing/test corpora much faster. 'skip ci' because changes do not affect our CI. ## 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/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 Jan 21 14:23:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 13:23:25 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: @jonsger I just downloaded a gnutls-3.6.5 archive; in the ./configure script I see `64497 _guile_versions_to_search="2.0 1.8"` If you have a correct guile.m4 file that gets pulled in by "autoreconf" when rebuilding the "configure" script that line should include the string from the guile.m4 file. Does manually patching the above line (and running configure ...) fix the issue on your system? @nmav I think the guile.m4 file is provided by another package (maybe guile itself, though I also saw it as part of the "autogen" tool). Hence I agree with @jonsger that a MR against gnutls is probably not appropriate. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133323973 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 14:29:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 13:29:24 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: @sbirkholz Ahm, hups. I run it from the git checkout. At openSUSE we use [this patch](https://build.opensuse.org/package/view_file/security:tls/gnutls/gnutls-enbale-guile-2.2.patch?expand=1) as we use the release tarball and it fixes the issue. It's the one I posted in the initial comment. On openSUSE the `guile.m4` file is part of the guile-devel package. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133325980 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 14:55:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 13:55:42 +0000 Subject: [gnutls-devel] GnuTLS | add API to get access to early exporter (#329) In-Reply-To: References: Message-ID: mentioned in: https://daniel.haxx.se/blog/2019/01/21/quic-and-missing-apis/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/329#note_133335616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 15:31:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 14:31:39 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: @nmav IMO we shouldn't do anything as long as we can't reproduce or at least find a %n usage in our code. I can't even find a *printf %n usage in gnulib. Maybe the issue isn't reproducible with latest code / dependencies and that's why @chouquette has no new info !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133347645 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:20:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:20:49 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: The '%n' use is not in our code but in the gnulib emulation of `vasprintf()`. At this point what we know is that the old code was working ok on android (I know vlc and openconnect), and the gnulib code fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133364942 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:39:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:39:14 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Maybe the old code didn't support %n ? So it just did nothing and VLC didn't crash ? > The '%n' use is not in our code but in the gnulib emulation of vasprintf(). You mean, gnulib's vasprintf() *introduces* a %n were no one was before ? If that is true, that must change... Could give me a pointer to the code line(s) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133371395 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:47:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:47:08 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Check `vasnprintf.c` file. The by patch by @chouquette was around line 4875. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133374022 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:53:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:53:23 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Thank you. I do not think this needs to be confidential (priority strings are provided by the user of the app), though I think it is something we should address in the upcoming release (updated milestone). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_133376063 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:54:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:54:30 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Reassigned Issue 677 https://gitlab.com/gnutls/gnutls/issues/677 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:56:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:56:09 +0000 Subject: [gnutls-devel] GnuTLS | tests/rng-op-key extrmely slow on the MinGW runners (#669) 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/669 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:56:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:56:47 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from maxhrt33@aim.com): Trust list bug? (#666) 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/666 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:57:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:57:04 +0000 Subject: [gnutls-devel] GnuTLS | Not possible to build tests on macOS. (#660) 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/660 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 16:59:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 15:59:56 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Ah click. I have been there and forgotten meanwhile. Just sent a reminder to gnulib ML. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133378378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:47:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:47:27 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Are they really UB? C99 states that unsigned integers are treated as "modulo" and silently wrap around. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_133394865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:58:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:58:40 +0000 Subject: [gnutls-devel] GnuTLS | Tests with RSA-PSS private_key and rsae/rsa-pss signature schemes. (#646) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/646 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:58:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:58:49 +0000 Subject: [gnutls-devel] GnuTLS | Unencrypted Finished msg is rejected with incorrect Alert (#643) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/643 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:58:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:58:57 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.6 (#634) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #634: https://gitlab.com/gnutls/gnutls/issues/634 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:59:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:06 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_PKCS11_TOKEN_MODNAME is unavailable when a provider is manually loaded (#633) 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/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 Mon Jan 21 17:59:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:15 +0000 Subject: [gnutls-devel] GnuTLS | Verify that certtool --outder does not output textual data (#627) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:59:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:25 +0000 Subject: [gnutls-devel] GnuTLS | session resumption: ability to limit resumption to TLS 1.3+ connections (#477) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/477 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:59:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:36 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli-debug should test whether RSA key exchange is enabled (#449) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:59:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli-debug should test whether RSA key exchange is enabled (#449) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 17:59:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 16:59:52 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-XTS mode (#354) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.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/354 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 18:02:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 17:02:47 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Do you know why the failure in CI is? Is that on latest master? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133399228 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 19:07:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 18:07:42 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: There is a failure for psk-file on Debian.cross.arm-linux-gnueabihf-ver7, I don't know why. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133414380 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 20:23:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 19:23:12 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect handling of session resumption with changed ClientHello (#657) 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/657 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 20:46:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 19:46:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_pkcs11_privkey_import_url: enable RSA-PSS only when an RSA key can sign (!884) References: Message-ID: New Merge Request !884 https://gitlab.com/gnutls/gnutls/merge_requests/884 Branches: tmp-key-rsa-pss 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 * [x] Code modified for feature * [x] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 20:46:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 19:46:52 +0000 Subject: [gnutls-devel] GnuTLS | PKCS#11: RSA-PSS should be enabled only when the private key can be used for signing (#667) In-Reply-To: References: Message-ID: Reassigned Issue 667 https://gitlab.com/gnutls/gnutls/issues/667 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/667 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 20:59:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 19:59:10 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Unfortunately I could not build TLS-Attacker locally. I will provide an MR which may address the issue, but I have no way to verify. ``` [ERROR] No goals have been specified for this build. You must specify a valid lifecycle phase or a goal in the format : or :[:]:. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1] org.apache.maven.lifecycle.NoGoalSpecifiedException: No goals have been specified for this build. You must specify a valid lifecycle phase or a goal in the format : or :[:]:. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:97) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:566) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoGoalSpecifiedException ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_133436239 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 21:00:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 20:00:32 +0000 Subject: [gnutls-devel] GnuTLS | Various alert-related fixes (!885) References: Message-ID: New Merge Request !885 https://gitlab.com/gnutls/gnutls/merge_requests/885 Branches: tmp-alerts-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 gnutls_alert_send_appropriate: do not send alert to peer on all errors alert: associate unsupported curve alerts with handshake failure ## 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/885 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 21:00:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 20:00:52 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Could you verify that !885 addresses the issue? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_133436514 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 21:01:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 20:01:11 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Reassigned Issue 672 https://gitlab.com/gnutls/gnutls/issues/672 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 21:02:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 20:02:08 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #677: https://gitlab.com/gnutls/gnutls/issues/677 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 21:26:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 20:26:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: @jonsger @nmav I just tried with a git checkout on my home machine; when running the ./bootstrap I see (somewhat towards the end) > autoreconf: running: aclocal -I m4 --force -I m4 -I src/libopts/m4 -I src/gl/m4 -I lib/unistring/m4 --install aclocal: installing 'm4/guile.m4' from '/usr/share/aclocal/guile.m4' aclocal: installing 'm4/pkg.m4' from '/usr/share/aclocal/pkg.m4' autoreconf: configure.ac: tracing so the guile.m4 from /usr/share/aclocal gets pulled in. The resulting "configure" script has > 63204 _guile_versions_to_search="2.2 2.0 1.8" and successfully enables the Guile wrappers. The distro I am on uses the release tarballs and just runs ./configure with some parameters, so using your patch to fix configure is also fine! I agree that my broken guile.m4 file is totally unrelated to the issue at hand; it was just a further complication on my system. Hope it helps! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133441814 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 21 22:42:44 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 21 Jan 2019 21:42:44 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Not really UB, but such behavior is dangerous if not coded intentionally. And in the later case such "tricks" should be documented / marked. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_133465053 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 08:21:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 07:21:50 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: I've updated to guile-2.2 on the system I use for release, but I don't feel that should be sufficient. Should we require guile-2.2 present when doing a `make dist`? Anyone to suggest a patch? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133532785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 08:23:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 07:23:13 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Is that a glitch (can you restart it), or it does have to do with adding the `-latomic`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133533026 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 08:39:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 07:39:56 +0000 Subject: [gnutls-devel] GnuTLS | Avoid excessive CPU usage in gnutls_idna_map() (!881) In-Reply-To: References: Message-ID: Merge Request !881 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/881 Branches: tmp-fix-fuzzer-timeout to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 09:02:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 08:02:34 +0000 Subject: [gnutls-devel] GnuTLS | Avoid excessive CPU usage in gnutls_idna_map() (!881) In-Reply-To: References: Message-ID: Merge Request !881 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/881 Branches: tmp-fix-fuzzer-timeout to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/881 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 10:32:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 09:32:02 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: I restarted the pipeline and it fails beacause of the "one hour timeout", how can I increase this timer? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133588634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 10:37:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 09:37:19 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Settings -> Ci/Cd -> General pipelines -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133590821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 13:52:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 12:52:13 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) In-Reply-To: References: Message-ID: I wouldn't say it is nice, but yes, it technically would be compliant. Would you create test cases to verify that behaviour? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/676#note_133669883 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 13:55:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 12:55:05 +0000 Subject: [gnutls-devel] GnuTLS | test the reception of multiple and split async handshake messages (NST) (#511) In-Reply-To: References: Message-ID: the PR is merged, but the version that was ultimately merged creates larger tickets than the orginally proposed ones, making calculation from https://github.com/tomato42/tlslite-ng/pull/287#issuecomment-403893329 incorrect now -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/511#note_133670851 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 14:02:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 13:02:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: The guile.m4 file seems to be provided by the guile package on most distributions; if upstream Guile specifies a "_guile_versions_to_search" string i'd assume that software trying to interface with Guile can expect to work with those versions. The configure script will check the actual version installed on the downstream users' computer against this string - so if the version of Guile installed on the system you build the releases on is the most recent version of Guile that works with GnuTLS, everything should be fine! When Guile-3.0 is released, they'll most likely prepare a new guile.m4 file which might drop prior versions from the "_guile_versions_to_search" string; in that case GnuTLS might not compile on systems with Guile-3.0 only, and the bindings would have to be updated. I feel like having the most recent version of Guile (that works with GnuTLS) on the release system should suffice. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_133673248 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 14:18:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 13:18:51 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Thanks, pipeline is now ok. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133678649 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 15:54:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 14:54:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) References: Message-ID: New Merge Request !886 https://gitlab.com/gnutls/gnutls/merge_requests/886 Branches: tmp-record-size-limit-fixes to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list As !879 seems to require some more work, this is split off from it towards 3.6.6 release. ## 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/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 21:18:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 20:18:01 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on configure.ac: > AC_CHECK_HEADERS([netinet/tcp.h]) > AC_CHECK_HEADERS([stdatomic.h]) > > +AC_SEARCH_LIBS([__atomic_load_4], [atomic], [AC_SUBST([LIBATOMIC_LIBS], [-latomic])]) Any reason for searching for `__atomic_load_4` and not for a function used by atomic.h? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878#note_133814013 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 21:18:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 20:18:07 +0000 Subject: [gnutls-devel] GnuTLS | configure.ac: check if libatomic is needed (!878) In-Reply-To: References: Message-ID: Reassigned Merge Request 878 https://gitlab.com/gnutls/gnutls/merge_requests/878 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/878 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 21:23:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 20:23:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Is that ready for merge? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_133815203 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 22:28:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 21:28:40 +0000 Subject: [gnutls-devel] GnuTLS | gnutls.pc: unnecessary pathname in Libs.private (#675) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #675: https://gitlab.com/gnutls/gnutls/issues/675 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/675 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 22 22:28:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 22 Jan 2019 21:28:40 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Merge Request !877 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/877 Branches: tmp-fix-libs-private to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 08:45:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 07:45:59 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) References: Message-ID: New Merge Request !887 https://gitlab.com/gnutls/gnutls/merge_requests/887 Branches: tmp-test-tickets to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This introduces tests for the reception (parsing) of multiple tickets by a gnutls client. It uses the tlslite-ng server because unlike a gnutls server, tlslite-ng does send multiple tickets in a single record. That way we test that we can parse both ways of sending tickets. ## Checklist * [x] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 08:47:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 07:47:23 +0000 Subject: [gnutls-devel] GnuTLS | test the reception of multiple and split async handshake messages (NST) (#511) In-Reply-To: References: Message-ID: Reassigned Issue 511 https://gitlab.com/gnutls/gnutls/issues/511 Assignee changed from Hubert Kario to Nikos Mavrogiannopoulos and Hubert Kario -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/511 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 09:35:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 08:35:39 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: A variant of the patch made it to gnulib: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6c0f109fb98501fc8d65ea2c83501b45a80b00ab -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_133999391 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 10:11:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 09:11:40 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Sorry I didn't get any notification from this thread, I haven't been able to reproduce the issue at all. As you mention earlier in the thread, I also don't the presence of a `%n` in GnuTLS (or VLC for that matter) is relevant. My understanding is that GNUlib uses %n as a fallback to compute a correct return value on some systems, so it will issue a printf like call with a `%n`, regardless of the format string passed to it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_134010479 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 10:21:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 09:21:12 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Thanks for your investigations ! I'll create a MR with the latest gnulib, which then should fix this issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653#note_134033618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 11:25:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 10:25:02 +0000 Subject: [gnutls-devel] build-images | Update Debian package list (!17) References: Message-ID: New Merge Request !17 https://gitlab.com/gnutls/build-images/merge_requests/17 Branches: tmp-debian-packages 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/17 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 11:25:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 10:25:07 +0000 Subject: [gnutls-devel] build-images | Update Debian package list (!17) In-Reply-To: References: Message-ID: Merge Request !17 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/17 Branches: tmp-debian-packages 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/17 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 11:49:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 10:49:01 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!888) References: Message-ID: New Merge Request !888 https://gitlab.com/gnutls/gnutls/merge_requests/888 Branches: tmp-update-gnulib 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 #653 (printf %n crashes on Android) ## 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/888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 12:30:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 11:30:19 +0000 Subject: [gnutls-devel] GnuTLS | Various alert-related fixes (!885) In-Reply-To: References: Message-ID: Merge Request !885 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/885 Branches: tmp-alerts-fix to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/885 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 12:40:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 11:40:03 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 (Dec 1, 2018?Jan 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 12:48:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 11:48:54 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Looking at priority.c:1266. The macro REMOVE_TLS13_IN_LOOP seems wrong or at least the following code. REMOVE_TLS13_IN_LOOP always 'continues' (jumps to the main loop) when `vers->tls13_sem` is set. That means that the following code ``` if (vers->tls13_sem) have_tls13 = 1; ``` is never executed and thus `have_tls13` stays always 0. But `have_tls13` is also checked later... Please review ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134092641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:00:54 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:00:54 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!888) In-Reply-To: References: Message-ID: Merge Request !888 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/888 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:02:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:02:47 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Reassigned Issue 653 https://gitlab.com/gnutls/gnutls/issues/653 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:05:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:05:59 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/887 was reviewed by Daiki Ueno -- Daiki Ueno started a new discussion on tests/suite/multi-ticket-reception.sh: > +srcdir="${srcdir:-.}" > +TLSPY_SERV="${srcdir}/tls-fuzzer/tlslite-ng/scripts/tls.py" > +PYPATH="${srcdir}/tls-fuzzer/tlsfuzzer/" So this relies on the symlinks set up by the `tls-fuzzer/*` tests. Maybe good to check the existence of the symlinks and abort if not? Or even, could it just point to `${srcdir}/tls-fuzzer/tlslite-ng`? -- Daiki Ueno started a new discussion on tests/suite/multi-ticket-reception.sh: > +wait_server ${PID} > + > +${VALGRIND} "${CLI}" -p "${PORT}" 127.0.0.1 --priority NORMAL:-VERS-ALL:+VERS-TLS1.3 --insecure +wait > + > +echo "Checking whether receiving 2 tickets in the same record succeeds" "3 tickets" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:06:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:06:06 +0000 Subject: [gnutls-devel] GnuTLS | Various alert-related fixes (!885) 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/885#note_134113798 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:06:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:06:35 +0000 Subject: [gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #672: https://gitlab.com/gnutls/gnutls/issues/672 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:06:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:06:35 +0000 Subject: [gnutls-devel] GnuTLS | Various alert-related fixes (!885) In-Reply-To: References: Message-ID: Merge Request !885 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/885 Branches: tmp-alerts-fix to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/885 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:16:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:16:12 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Other than those it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887#note_134116697 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:16:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:16:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: > I feel like having the most recent version of Guile (that works with GnuTLS) on the release system should suffice. As I said this cannot be guaranteed unless we test for it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_134116701 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:20:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:20:48 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: I made some changes to the Debian CI images this morning, including "guile-2.0 -> guile-2.2". Or do you think of a test during 'make distcheck' ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_134118042 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:21:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:21:11 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from android-developer-preview@google.com): [8-5416000025036] GnuTLS open source library causes apps to crash (#653) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #653: https://gitlab.com/gnutls/gnutls/issues/653 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/653 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:21:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:21:12 +0000 Subject: [gnutls-devel] GnuTLS | Update gnulib (!888) In-Reply-To: References: Message-ID: Merge Request !888 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/888 Branches: tmp-update-gnulib to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:21:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:21:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_pkcs11_privkey_import_url: enable RSA-PSS only when an RSA key can sign (!884) In-Reply-To: References: Message-ID: Merge Request !884 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/884 Branches: tmp-key-rsa-pss to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:24:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:24:46 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/suite/multi-ticket-reception.sh: > +# under the terms of the GNU General Public License as published by the > +# Free Software Foundation; either version 3 of the License, or (at > +# your option) any later version. > +# > +# GnuTLS is distributed in the hope that it will be useful, but > +# WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +# General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with GnuTLS; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + > +srcdir="${srcdir:-.}" > +TLSPY_SERV="${srcdir}/tls-fuzzer/tlslite-ng/scripts/tls.py" > +PYPATH="${srcdir}/tls-fuzzer/tlsfuzzer/" Unfortunately it doesn't work as it misses ecdsa :( I've added some code to create the links here too... Quite ugly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887#note_134119159 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:24:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:24:55 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/suite/multi-ticket-reception.sh: > + > + > +. "${srcdir}/../scripts/common.sh" > + > +KEY1=${srcdir}/tls-fuzzer/tlslite-ng/tests/serverX509Key.pem > +CERT1=${srcdir}/tls-fuzzer/tlsfuzzer/tests/serverX509Cert.pem > + > + > +echo "Checking whether receiving 1 ticket succeeds (sanity)" > + > +eval "${GETPORT}" > +PYTHONPATH="${PYPATH}" ${TLSPY_SERV} server --tickets 1 -k ${KEY1} -c ${CERT1} 127.0.0.1:${PORT} & > +PID=$! > +wait_server ${PID} > + > +${VALGRIND} "${CLI}" -p "${PORT}" 127.0.0.1 --priority NORMAL:-VERS-ALL:+VERS-TLS1.3 --insecure From gnutls-devel at lists.gnutls.org Wed Jan 23 13:25:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:25:02 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/suite/multi-ticket-reception.sh: > + > +echo "Checking whether receiving 1 ticket succeeds (sanity)" > + > +eval "${GETPORT}" > +PYTHONPATH="${PYPATH}" ${TLSPY_SERV} server --tickets 1 -k ${KEY1} -c ${CERT1} 127.0.0.1:${PORT} & > +PID=$! > +wait_server ${PID} > + > +${VALGRIND} "${CLI}" -p "${PORT}" 127.0.0.1 --priority NORMAL:-VERS-ALL:+VERS-TLS1.3 --insecure + fail ${PID} "1. handshake should have succeeded!" > + > + > +kill ${PID} > +wait > + > +echo "Checking whether receiving 2 tickets in the same record succeeds" Fixed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887#note_134119235 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:29:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:29:05 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: All discussions on Merge Request !887 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/887 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:29:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:29:10 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Merge Request !887 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/887 Branches: tmp-test-tickets to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 13:52:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 12:52:59 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: > REMOVE_TLS13_IN_LOOP always 'continues' (jumps to the main loop) when vers->tls13_sem is set. That means that the following code In [that part of the code](https://gitlab.com/gnutls/gnutls/blob/master/lib/priority.c#L1266), the invocation of `REMOVE_TLS13_IN_LOOP` macro is guarded with `have_null || have_srp || have_rsa_psk`, so it's not 'always' and should work as described in [the comment](https://gitlab.com/gnutls/gnutls/blob/master/lib/priority.c#L1263), as far as I understand it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134127824 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 14:34:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 13:34:59 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Absolutely right. So we can easily do the `REMOVE_TLS13_IN_LOOP` outside the main loop. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134142540 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 14:56:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 13:56:17 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: > So we can easily do the REMOVE_TLS13_IN_LOOP outside the main loop. That would require 2-path iterations over the array, no? The current logic is something like: ``` for i in 0...n { if entries[i] is NULL, SRP, or PSK { // REMOVE_TLS13_IN_LOOP if entries[i] is TLS 1.3 { entries[i...n] <- entries[i+1...n] // (*) retry the loop from i } } ... } ``` I don't see anything wrong here, though it might be a little cleaner if (*) is rewritten using memmove, and `REMOVE_TLS13_IN_LOOP` doesn't take `i` as the argument. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134149897 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:01:10 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:01:10 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: That looks like a N^2 behavior. What about ``` if (have_null || have_srp || have_rsa_psk) { for (i = j = 0; i < priority_cache->protocol.num_priorities; i++) { vers = version_to_entry(priority_cache->protocol.priorities[i]); if (!vers || !vers->tls13_sem) priority_cache->protocol.priorities[j++] = priority_cache->protocol.priorities[i]; } } priority_cache->protocol.num_priorities = j; ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134151619 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:06:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:06:19 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Reassigned Issue 679 https://gitlab.com/gnutls/gnutls/issues/679 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:22:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:22:57 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) References: Message-ID: New Merge Request !889 https://gitlab.com/gnutls/gnutls/merge_requests/889 Branches: tmp-priority-linear 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 Cleans up the code in priority.c/set_ciphersuite_list() to use a linear approach to remove the TLS1.3 ciphersuites (if needed). As a side effect, the integer overflows of #679 are fixed. Closes #679 ## 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/889 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:24:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:24:58 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: @dueno !889 has the proposed code, please check if you agree or not. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134160419 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:39:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:39:34 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Sorry, I'm not really convinced, though the patch indeed looks cleaner. My concern is that it could actually be more costly, when the majority of the items are TLS 1.2 and if we can assume that `REMOVE_TLS13_IN_LOOP` works in amortized constant time (with the help of compiler optimization). However, given that the array wouldn't contain millions of items, that probably wouldn't matter. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134165650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 15:58:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 14:58:30 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: To convince you :-) ... The macro contained a loop over all items beginning at the current position of the main loop. (And I can not see how a compiler could optimize that out.) Example: With N being `priority_cache->protocol.num_priorities`, the 'macro loop's body will be executed N+(N-1)+(N-2)+... times. This is sum(1..N) which is (N^2+N)/2. The new approach uses exactly N executions of the loop body. With N=10 this is 55 against 10. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134173437 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:01:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:01:17 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on src/udp-serv.c: > recvfrom(sock, buffer, sizeof(buffer)-1, MSG_PEEK, > (struct sockaddr *) &cli_addr, > &cli_addr_size); > - if (ret > 0) { > + > + /* only accept a valid client hello */ > + if (ret > 13 && buffer[0] == 22 && buffer[13] == 1) { `13` and `22` look like magic numbers here. Can we get rid of them somehow? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863#note_134174981 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:01:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:01:38 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: Other than that comment LGTM. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863#note_134175213 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:04:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:04:12 +0000 Subject: [gnutls-devel] GnuTLS | The flag %NO_EXTENSIONS is disabling extension support while being functional (!870) In-Reply-To: References: Message-ID: Can we somehow resolve this UB? Would it be easier to make an error to use `%NO_EXTENSIONS` with TLS 1.3? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/870#note_134176768 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:04:16 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:04:16 +0000 Subject: [gnutls-devel] GnuTLS | The flag %NO_EXTENSIONS is disabling extension support while being functional (!870) In-Reply-To: References: Message-ID: Merge Request !870 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/870 Branches: tmp-fix-no-extensions to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/870 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:11:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:11:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: @ansasaki added test job fails on multiple tests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_134180443 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:16:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:16:58 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_pkcs11_privkey_import_url: enable RSA-PSS only when an RSA key can sign (!884) In-Reply-To: References: Message-ID: Merge Request !884 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/884 Branches: tmp-key-rsa-pss to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:17:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:17:02 +0000 Subject: [gnutls-devel] GnuTLS | PKCS#11: RSA-PSS should be enabled only when the private key can be used for signing (#667) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #667: https://gitlab.com/gnutls/gnutls/issues/667 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/667 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:17:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:17:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_pkcs11_privkey_import_url: enable RSA-PSS only when an RSA key can sign (!884) In-Reply-To: References: Message-ID: Merge Request !884 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/884 Branches: tmp-key-rsa-pss to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:31:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:31:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: wouldn't it be prudent to add tlsfuzzer test cases for this too? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886#note_134188583 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:31:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:31:40 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/merge_requests/886 was reviewed by Hubert Kario -- Hubert Kario started a new discussion on lib/ext/record_size_limit.c: > .gid = GNUTLS_EXTENSION_RECORD_SIZE_LIMIT, > - .parse_type = GNUTLS_EXT_TLS, > + .parse_type = GNUTLS_EXT_MANDATORY, it is only when the client sent the extension, isn't it? (and the client doesn't have to send it for resumption?) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:33:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:33:19 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) References: Message-ID: New Issue was created. Issue 680: https://gitlab.com/gnutls/gnutls/issues/680 Author: Nathaniel McCallum Assignee: Currently, setting PSK credential callbacks with GnuTLS results in PSK silently not working. You also have to enable PSK in the priorities. There is no documentation on this problem and the behavior is cryptic. I propose enabling the PSK family of algorithms by default. This way, setting the PSK callbacks will work by default. If an admin overrides this with "-PSK" (etc), it should forcibly disable PSK regardless of the callbacks. I realize this raises the question of `PSK` vs `DHE-PSK` vs `ECDHE-PSK`. There are no known weaknesses with `ECDHE-PSK` or `DHE-PSK`. So these should be preferred to `PSK` because they provide PFS. Should a weakness be discovered, they can be demoted. Likewise, should a user feel paranoid about asymmetric cryptography, they can simply override the default. -- 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 Wed Jan 23 16:34:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:34:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: All discussions on Merge Request !863 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/863 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:34:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:34:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: Merge Request !863 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/863 Branches: tmp-fix-udp-serv to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:36:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:36:24 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) In-Reply-To: References: Message-ID: The question of the priority of `DHE-PSK` vs `ECDHE-PSK` can be solved by falling back to the current GnuTLS policy on asymmetric key exchanges. For the purposes of this bug, I don't have a preference. I just want the user/developer experience to be less vague. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/680#note_134190273 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:37:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:37:38 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) In-Reply-To: References: Message-ID: Also, should PSK need to be demoted due to a future weakness, documentation should be added to the PSK credential callback APIs to specify the need to enable PSK in the priorities. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/680#note_134190827 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:41:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:41:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/udp-serv.c: > recvfrom(sock, buffer, sizeof(buffer)-1, MSG_PEEK, > (struct sockaddr *) &cli_addr, > &cli_addr_size); > - if (ret > 0) { > + > + /* only accept a valid client hello */ > + if (ret > 13 && buffer[0] == 22 && buffer[13] == 1) { Certainly. Sent an update. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863#note_134192468 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:41:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:41:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix FIPS integrity self tests (!873) In-Reply-To: References: Message-ID: @lumag Yes, sorry about this. I will fix it, but it may take some time. I will hopefully get back to this in the next weeks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/873#note_134192475 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 16:46:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 15:46:58 +0000 Subject: [gnutls-devel] GnuTLS | Enable PSK by default (#680) 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/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 Wed Jan 23 17:09:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 16:09:08 +0000 Subject: [gnutls-devel] GnuTLS | configure fails on *ubuntu 18.04.1 LTS because libnettle is not found (#681) References: Message-ID: New Issue was created. Issue 681: https://gitlab.com/gnutls/gnutls/issues/681 Author: Matthias Gierlings Assignee: Trying to verify the fix for #682, I was unable build the latest master on Kubuntu 18.04.1 LTS. The last version I managed to build without problem is `tags/gnutls_3_6_4`. Building the latest master `./configure` aborts with the following output: ``` checking for NETTLE... no configure: error: *** *** Libnettle 3.4.1 was not found. ``` Using the version tagged `gnutls_3_6_5`: ``` checking for NETTLE... no configure: error: *** *** Libnettle 3.4 was not found. ``` Libnettle shipped with the distribution: ``` ldconfig -p | grep nettle && apt show nettle* libnettle.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnettle.so.6 libnettle.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnettle.so Package: nettle-dev Version: 3.4-1 Priority: optional Section: libdevel Source: nettle Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Magnus Holmgren Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 2.515 kB Depends: libnettle6 (= 3.4-1), libhogweed4 (= 3.4-1), libgmp10-dev, dpkg (>= 1.15.4) | install-info Conflicts: libnettle-dev Replaces: libnettle-dev Homepage: http://www.lysator.liu.se/~nisse/nettle/ Supported: 5y Download-Size: 951 kB APT-Manual-Installed: yes ... ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/681 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 17:55:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 16:55:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/record_size_limit.c: > .name = "Record Size Limit", > .tls_id = 28, > .gid = GNUTLS_EXTENSION_RECORD_SIZE_LIMIT, > - .parse_type = GNUTLS_EXT_TLS, > + .parse_type = GNUTLS_EXT_MANDATORY, sorry, the commit message was confusing; it is about parsing not sending. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886#note_134220119 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 17:55:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 16:55:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: All discussions on Merge Request !886 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/886 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 17:56:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 16:56:32 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: > wouldn't it be prudent to add tlsfuzzer test cases for this too? I added the test now, though most of them still fail because of the lower limits, etc., which we are not addressing in this MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886#note_134220780 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 18:33:41 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 17:33:41 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Yes I know :-) I was just wondering what if the compiler might optimize the inner loop as though it's has [O(1) amortized bound](https://en.wikipedia.org/wiki/Amortized_analysis), e.g., with special memory copy instructions. After reading the surrounding code more closely, I like your approach more; let me approve the MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679#note_134234879 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 18:39:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 17:39:09 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/priority.c: > * a pre-TLS1.2 protocol is there; that is because servers which > * do not support TLS1.3 will negotiate TLS1.2 if seen a TLS1.3 handshake */ > if (unlikely((!have_psk && tlsmax && tlsmax->id >= GNUTLS_TLS1_3 && priority_cache->groups.size == 0)) || > - (!have_tls12 && have_pre_tls12 && have_tls13)) { > - for (i = 0; i < priority_cache->protocol.num_priorities; i++) { > + (!have_tls12 && have_pre_tls12 && have_tls13)) > + { [Opening brace should be on the previous line](https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889#note_134237284 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 18:45:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 17:45:55 +0000 Subject: [gnutls-devel] GnuTLS | configure fails on *ubuntu 18.04.1 LTS because libnettle is not found (#681) In-Reply-To: References: Message-ID: Issue was closed by Andreas Metzler Issue #681: https://gitlab.com/gnutls/gnutls/issues/681 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/681 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 18:45:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 17:45:55 +0000 Subject: [gnutls-devel] GnuTLS | configure fails on *ubuntu 18.04.1 LTS because libnettle is not found (#681) In-Reply-To: References: Message-ID: Both 3.6.5 and master need nettle 3.4.1, as documented in NEWS. The fact that the error message in 3.6.5 is incorrect is known, and as seen above is already fixed in master by !833. You need to upgrade nettle to build newer gnutls. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/681#note_134239684 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 18:50:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 17:50:21 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: Merge Request !889 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/889 Branches: tmp-priority-linear to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 19:20:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 18:20:25 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/priority.c: > * a pre-TLS1.2 protocol is there; that is because servers which > * do not support TLS1.3 will negotiate TLS1.2 if seen a TLS1.3 handshake */ > if (unlikely((!have_psk && tlsmax && tlsmax->id >= GNUTLS_TLS1_3 && priority_cache->groups.size == 0)) || > - (!have_tls12 && have_pre_tls12 && have_tls13)) { > - for (i = 0; i < priority_cache->protocol.num_priorities; i++) { > + (!have_tls12 && have_pre_tls12 && have_tls13)) > + { Having the brace at the end of a continuation line is harder to read when you quickly read source code. This is just my personal observation/experience after so many years of reading code. Rules are for breaking them ;-) But in this case I don't mind (it isn't my project). I'll amend it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889#note_134251478 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 19:23:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 18:23:45 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: All discussions on Merge Request !889 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/889 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 19:24:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 18:24:17 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: Thanks for review ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889#note_134252710 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:10:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:10:23 +0000 Subject: [gnutls-devel] GnuTLS | Incorrect error returned in TLS 1.3 when an unsupported signature algorithm is used by a client for Certificate VErify message signatures (#682) References: Message-ID: New Issue was created. Issue 682: https://gitlab.com/gnutls/gnutls/issues/682 Author: Simo Sorce Assignee: ## Description of problem: As I was writing tlsfuzzer tests to probe the correctness of client certificate handling by server implementations, it stood out that GNUTLS is returning a handshake_failure error when a client sends an RSA pkcs1 signature that the server should not accept. The error returned should be illegal_parameter in this case (openssl and tlslite conform). Here is the description of the 2 errors from the RFC: ``` handshake_failure: Receipt of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. illegal_parameter: A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect. ``` The second correctly describes the situation, the client misbehaved sending a field (signature algorithm selected) that is inconsistent with other fields (the server sent proper support signature algorithms lists in the CertificateRequest message). A handshake_failure is improper because it is applicable only when the server, after parsing a list of permissible options, discovers it can use none. It is not the case here as the server is the *receiver*, and the client sent an invalid parameter, not a field to negotiate upon. HTH. Simo ## Version of gnutls used: gnutls-3.6.5-2.fc29.x86_64 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora ## How reproducible: Run the tests introduced here: https://github.com/tomato42/tlsfuzzer/pull/496 using the following command line to run a GnuTLS server: `$ gnutls-serv --http --priority NORMAL:-VERS-ALL:+VERS-TLS1.3 -p 4433 --x509keyfile=tests/serverX509Key.pem --x509certfile=tests/serverX509Cert.pem` Steps to Reproduce: * run the server * run the test * observe the errors reported by the test ## Actual results: Invalid pkcs1 signatures produce a handshake_failure error ## Expected results: Invalid pkcs1 signatures produce an illegal_paramter error -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/682 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:12:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:12:14 +0000 Subject: [gnutls-devel] GnuTLS | test the reception of multiple and split async handshake messages (NST) (#511) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #511: https://gitlab.com/gnutls/gnutls/issues/511 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/511 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:12:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:12:14 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) In-Reply-To: References: Message-ID: Merge Request !887 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/887 Branches: tmp-test-tickets to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/887 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:12:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:12:40 +0000 Subject: [gnutls-devel] GnuTLS | tests: added tests for multiple ticket reception (!887) 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/887#note_134268869 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:17:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:17:34 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: This seems to make travis CI (macosx) fail: https://travis-ci.org/gnutls/gnutls/builds/483104453 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_134270442 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:34:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:34:37 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: Most likely is this part in lib/Makefile.am: ``` if HAVE_LIBUNISTRING thirdparty_libadd += $(LTLIBUNISTRING) else libgnutls_la_LIBADD += unistring/libunistring.la endif ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_134274973 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 20:36:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 19:36:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: `./configure` doesn't print out $LIBS at the end... but found in the messages: On success ``` checking for libunistring... yes checking how to link with libunistring... -L/usr/local/lib -lunistring ``` On failure ``` checking for library containing u8_normalize... -lunistring ``` Looks like there are two versions of libunistring installed on the TravisCI image. Can't investigate right now, but maybe tomorrow. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_134275302 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 21:12:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 20:12:08 +0000 Subject: [gnutls-devel] GnuTLS | .travis.yml: make macosx builds compile again (!890) References: Message-ID: New Merge Request !890 https://gitlab.com/gnutls/gnutls/merge_requests/890 Branches: tmp-fix-macosx 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 patch set avoids the call to submodule update (was not necessary), and fixes linking with libunistring. ## 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/890 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 21:14:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 20:14:48 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: runs at: https://travis-ci.org/nmav/gnutls/builds/483569538 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890#note_134284378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 21:41:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 20:41:30 +0000 Subject: [gnutls-devel] GnuTLS | Fix libs.private in gnutls.pc for multiarch builds (!877) In-Reply-To: References: Message-ID: I have a WIP patch at: https://gitlab.com/gnutls/gnutls/merge_requests/890 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/877#note_134289253 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 21:55:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 20:55:38 +0000 Subject: [gnutls-devel] libtasn1 | Detecting Bug in libtasn1-4.13 by fuzzing. (#4) In-Reply-To: References: Message-ID: @nmav: I understand your point. I wonder would it be possible to generate two "bundles" of the library. Bundle for developers would contain everything whereas bundle for production use would contain only the code use in production (i.e. not in compilation)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/4#note_134291609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 21:56:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 20:56:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: Looks like ``` Trying static linking with -L/usr/local/lib -L/usr/local/Cellar/nettle/3.4.1/lib -L/usr/local/Cellar/libtasn1/4.13/lib -L/usr/local/Cellar/p11-kit/0.23.14/lib -lgnutls -lgmp -lunistring -lidn2 none required -lhogweed -lgmp -lnettle -ltasn1 -lp11-kit ... clang: error: no such file or directory: 'none' clang: error: no such file or directory: 'required' ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890#note_134291898 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 22:14:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 21:14:36 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) 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/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 Wed Jan 23 22:15:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 21:15:09 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) In-Reply-To: References: Message-ID: @nmav As this is, technically, a new feature, I guess this is NOT for 3.6.6? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/386#note_134295398 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 22:27:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 21:27:26 +0000 Subject: [gnutls-devel] GnuTLS | set_ciphersuite_list(): Use linear approach to cleanup priorities (!889) In-Reply-To: References: Message-ID: Merge Request !889 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/889 Branches: tmp-priority-linear to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/889 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 22:27:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 21:27:26 +0000 Subject: [gnutls-devel] GnuTLS | Two integer overflows in priority.c (#679) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #679: https://gitlab.com/gnutls/gnutls/issues/679 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/679 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 23:48:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 22:48:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-serv: improvements in UDP server (!863) In-Reply-To: References: Message-ID: Merge Request !863 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/863 Branches: tmp-fix-udp-serv to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/863 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 23 23:48:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 22:48:45 +0000 Subject: [gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #632: https://gitlab.com/gnutls/gnutls/issues/632 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 00:14:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 23 Jan 2019 23:14:53 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) References: Message-ID: New Issue was created. Issue 683: https://gitlab.com/gnutls/gnutls/issues/683 Author: Nathaniel McCallum Assignee: I am unable to get GnuTLS and OpenSSL to play nicely together on IPv6. Here are the two commands: ``` $ cat tests/psk.txt foo:7df28f5439b5a051cc138b6e12128264 $ gnutls-serv -p 5000 --echo --priority NORMAL:+ECDHE-PSK:+DHE-PSK:+PSK --pskpasswd=psk.txt Warning: no private key and certificate pairs were set. Echo Server listening on IPv4 0.0.0.0 port 5000...done Echo Server listening on IPv6 :: port 5000...done * Accepted connection from IPv6 ::1 port 57192 on Wed Jan 23 17:59:01 2019 Error in handshake: An illegal parameter has been received. ``` ``` $ openssl s_client -connect [::1]:5000 -psk_identity foo -psk 7df28f5439b5a051cc138b6e12128264 CONNECTED(00000003) 139765944088384:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1528:SSL alert number 47 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 405 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 02:19:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 01:19:39 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: @nmav what about https://gitlab.com/GostCrypt/gnutls/tree/tmp-fix-macosx ? It passes build in Travis CI: https://travis-ci.org/GostCrypt/gnutls/builds/483649480 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890#note_134382777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 06:27:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:27:59 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) 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/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 Thu Jan 24 06:28:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:28:19 +0000 Subject: [gnutls-devel] GnuTLS | Allow non null terminated usernames for psk (#586) In-Reply-To: References: Message-ID: Seeing the above, I'm pinging you :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586#note_134410870 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 06:36:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:36:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: Thank you. Do we need `AC_MSG_FAILURE` if not found? I've updated it to check for the 'no' case too and replace FAILURE with NOTICE. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890#note_134411745 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 06:47:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:47:24 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on fuzz/get_all_corpora: > -#!/bin/sh -eu > +#!/bin/sh -u With the `-eu` or `-u` option when running without ARGV it does print a very obscure error -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_134412925 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 06:50:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:50:40 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Tried to review it, but the whole script is very cryptic to me. I could not fully understand what it is its purpose from README.md. Its name suggests downloading, however it also runs tests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_134413265 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 06:51:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 05:51:20 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: I'll be happy to merge as you are using it, however I think it would be nicer if we make clear what this script is used for. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_134413343 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 10:29:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 09:29:32 +0000 Subject: [gnutls-devel] GnuTLS | WIP: .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: Merge Request !890 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/890 Branches: tmp-fix-macosx to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 10:29:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 09:29:49 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: The script is already in the GnuTLS repo. The only change is to download a whole archive of corpora for a given fuzzer. Right now each single corpus file is downloaded separately, which takes ages. The errors come due to some don't provide corpora any longer. My guess is those fuzzers are 'done' (no new path discoveries in a while). I removed the -e so that the loop in `get_all_corpora` continues on error. Documenting the scripts better should be another issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_134461378 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 10:38:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 09:38:17 +0000 Subject: [gnutls-devel] GnuTLS | Fetch OSS-Fuzz corpora much faster [skip ci] (!883) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on fuzz/get_all_corpora: > -#!/bin/sh -eu > +#!/bin/sh -u What errors exactly ? If it'd due to downloading with gsutil: The errors come due to some don't provide corpora any longer. My guess is those fuzzers are 'done' (no new path discoveries in a while). I removed the -e so that the loop in get_all_corpora continues on error. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/883#note_134464234 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 12:25:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 11:25:26 +0000 Subject: [gnutls-devel] GnuTLS | Reconsidering use of VLAs and alloca() (#684) References: Message-ID: New Issue was created. Issue 684: https://gitlab.com/gnutls/gnutls/issues/684 Author: Tim R?hsen Assignee: Variable Length Arrays (VLAs) and alloca() are sometimes a very fast alternative to malloc() and are also very handy because a free() or cleanup is not needed. But VLAs and alloca() easily introduce security issues. Their use in code needs thorough care and manual review, basically with every code change that uses them directly or indirectly. It is a common vulnerability pattern that attackers gain control over the size of those stack allocations, enabling stack overflows, remote code execution, denial-of-service, and the like. Current prominent example is https://www.openwall.com/lists/oss-security/2019/01/09/3. As a security-related software project, we should not ignore such concerns. Not in the library code nor in the tools. IMO we should disallow VLAs and alloca() in our code, replace them appropriately and add an automatic check on MRs via the Gitlab CI. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 13:24:57 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 12:24:57 +0000 Subject: [gnutls-devel] GnuTLS | .travis.yml: make macosx builds compile again (!890) In-Reply-To: References: Message-ID: Merge Request !890 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/890 Branches: tmp-fix-macosx to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/890 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 13:30:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 12:30:05 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on tests/suite/tls-fuzzer/gnutls-nocert.json: > + "-e", "check if server accepts maximum size in TLS 1.0", > + "-e", "check if server accepts maximum size in TLS 1.3", > + "-e", "check if server accepts minimal size in TLS 1.0", > + "-e", "check if server accepts minimal size in TLS 1.1", > + "-e", "check if server accepts minimal size in TLS 1.2", > + "-e", "check if server accepts minimal size in TLS 1.3", > + "-e", "check interaction with sha256 prf", > + "-e", "check interaction with sha384 prf", > + "-e", "check server sent size in TLS 1.0", > + "-e", "check server sent size in TLS 1.3", > + "-e", "drop extension in TLS 1.3 session resumption", > + "-e", "HRR sanity", > + "-e", "modified extension in 2nd CH in HRR handshake", > + "-e", "renegotiation with changed limit", > + "-e", "renegotiation with dropped extension", > + "-e", "too large record in TLS 1.2", that shouldn't fail given any of the causes listed in comment -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886#note_134536194 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 13:37:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 12:37:58 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: All discussions on Merge Request !886 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/886 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 13:37:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 12:37:59 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/suite/tls-fuzzer/gnutls-nocert.json: > + "-e", "check if server accepts maximum size in TLS 1.0", > + "-e", "check if server accepts maximum size in TLS 1.3", > + "-e", "check if server accepts minimal size in TLS 1.0", > + "-e", "check if server accepts minimal size in TLS 1.1", > + "-e", "check if server accepts minimal size in TLS 1.2", > + "-e", "check if server accepts minimal size in TLS 1.3", > + "-e", "check interaction with sha256 prf", > + "-e", "check interaction with sha384 prf", > + "-e", "check server sent size in TLS 1.0", > + "-e", "check server sent size in TLS 1.3", > + "-e", "drop extension in TLS 1.3 session resumption", > + "-e", "HRR sanity", > + "-e", "modified extension in 2nd CH in HRR handshake", > + "-e", "renegotiation with changed limit", > + "-e", "renegotiation with dropped extension", > + "-e", "too large record in TLS 1.2", amended the comment as we actually accepts too large application_data records in TLS 1.2 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886#note_134538527 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 14:22:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 13:22:15 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: I can confirm that this works without problem on Debian stretch. This may be a Fedora specific issue. Alternatively, it may be a version-specific issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134556629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 15:00:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 14:00:59 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: I was able to reproduce the issue in a Debian unstable container. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134570013 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 15:06:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 14:06:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Merge Request !886 was approved by Hubert Kario Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/886 Branches: tmp-record-size-limit-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 15:30:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 14:30:45 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: This appears to be a regression. I am not able to reproduce it on a Debian stable container but I am able to reproduce it on a Debian testing container. So somewhere between 3.5.8-5+deb9u4 and 3.6.5-2. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134582002 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 15:44:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 14:44:14 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: It is failing in the SNI handling code introduced by 88b4f9036aefd0f8e20de6cae56b62be7a721b70. However, this seems like a correct behavior as RFC 6066 says: Literal IPv4 and IPv6 addresses are not permitted in "HostName". It should work if you supply the server name with: ``` openssl s_client -connect '[::1]:5000' -servername localhost6 -psk_identity foo -psk 7df28f5439b5a051cc138b6e12128264 ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134588376 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:03:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:03:32 +0000 Subject: [gnutls-devel] GnuTLS | Fix record_size_limit extension handling when resuming (!886) In-Reply-To: References: Message-ID: Merge Request !886 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/886 Branches: tmp-record-size-limit-fixes to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/886 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:06:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:06:23 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: Would it be possible to get an explicit error? The current situation is that we get a vague error on seemingly acceptable input. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134597197 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:30:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:30:01 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: The quick solution is to add debug info (using e.g. -d 4 for gnutls-serv): ``` |<4>| HSK[0x562884a06330]: Server name is not acceptable: '::1' ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134606183 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:36:12 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:36:12 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: @dueno What about using `GNUTLS_E_UNRECOGNIZED_NAME` instead of `GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER` (in server_name.c / _gnutls_server_name_recv_params()) ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134608336 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:38:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:38:30 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: That gives us ``` * Accepted connection from IPv6 ::1 port 36626 on Thu Jan 24 16:37:57 2019 Error in handshake: The SNI host name not recognised. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134609088 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:47:59 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:47:59 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) References: Message-ID: New Merge Request !891 https://gitlab.com/gnutls/gnutls/merge_requests/891 Branches: tmp-fix-sni-error 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 Changes gnutls-serv output from Error in handshake: An illegal parameter has been received. to Error in handshake: The SNI host name not recognised. when receiving an unacceptable SNI name. ## 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/891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 16:51:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 15:51:31 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: > RFC 6066 says: Literal IPv4 and IPv6 addresses are not permitted in "HostName". The checking code is ``` if (!(c_isalnum(str[i]) || str[i] == '-' || str[i] == '.')) return 0; ``` So IPv4 addresses are accepted. Just IPv6 not because they contain colons which are forbidden in DNS names. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134613679 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 17:54:02 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 16:54:02 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: > What about using GNUTLS_E_UNRECOGNIZED_NAME instead of GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER (in server_name.c / _gnutls_server_name_recv_params()) ? IMO illegal_parameter is more appropriate here according to the RFC: ``` illegal_parameter: A field in the handshake was incorrect or inconsistent with other fields. _This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect._ ``` and ``` unrecognized_name: Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension (see [RFC6066]). ``` That would allow clients to distinguish whether the error is in protocol level or configuration level. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134637845 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 18:55:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 17:55:09 +0000 Subject: [gnutls-devel] GnuTLS | certtool.1: fix formatting (!892) References: Message-ID: New Merge Request !892 https://gitlab.com/gnutls/gnutls/merge_requests/892 Project:Branches: ametzler/gnutls:tmp-ametzler-certtool-manpage-formatting to gnutls/gnutls:master Author: Andreas Metzler 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 The generated manpage was missing the full list for --key-type=, since the respective manpage line started with an apostrophe, which is a control character. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 19:48:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 18:48:45 +0000 Subject: [gnutls-devel] GnuTLS | certtool.1: fix formatting (!892) In-Reply-To: References: Message-ID: Merge Request !892 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/892 Project:Branches: ametzler/gnutls:tmp-ametzler-certtool-manpage-formatting 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/892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 19:55:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 18:55:42 +0000 Subject: [gnutls-devel] GnuTLS | certtool.1: fix formatting (!892) In-Reply-To: References: Message-ID: Merge Request !892 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/892 Project:Branches: ametzler/gnutls:tmp-ametzler-certtool-manpage-formatting 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/892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:13:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:13:38 +0000 Subject: [gnutls-devel] GnuTLS | The flag %NO_EXTENSIONS is disabling extension support while being functional (!870) In-Reply-To: References: Message-ID: What if we disable TLS1.3 in that case? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/870#note_134695161 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:13:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:13:53 +0000 Subject: [gnutls-devel] GnuTLS | The flag %NO_EXTENSIONS is disabling extension support while being functional (!870) In-Reply-To: References: Message-ID: Merge Request !870 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/870 Branches: tmp-fix-no-extensions to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/870 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:28:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:28:43 +0000 Subject: [gnutls-devel] GnuTLS | priorities: when %NO_EXTENSIONS is specified disable TLS1.3 (!893) References: Message-ID: New Merge Request !893 https://gitlab.com/gnutls/gnutls/merge_requests/893 Branches: tmp-define-no-extensions 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 his makes the behavior of this priority string option well-defined even when TLS1.3 is enabled. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/893 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:33:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:33:07 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/server_name.c: > DECR_LEN(data_size, len); > > if (type == 0) { /* NAME_DNS */ > - if (!_gnutls_dnsname_is_valid((char*)p, len)) > - return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + if (!_gnutls_dnsname_is_valid((char*)p, len)) { > + _gnutls_handshake_log > + ("HSK[%p]: Server name is not acceptable: '%.*s'\n", > + session, (int) len, p); > + return gnutls_assert_val(GNUTLS_E_UNRECOGNIZED_NAME); This error code is being mapped to alert `GNUTLS_A_UNRECOGNIZED_NAME` while on this alert we should send that this is an illegal parameter. What if we introduce a new error code (e.g., ILLEGAL_HOSTNAME) which maps to the illegal parameter alert? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_134698940 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:33:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:33:38 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: Milestone changed to Release of GnuTLS 3.6.6 (Dec 1, 2018?Jan 25, 2019) ( https://gitlab.com/gnutls/gnutls/milestones/18 ) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 20:36:03 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 19:36:03 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: So does the following openssl command: ``` openssl s_client -connect [::1]:5000 -psk_identity foo -psk 7df28f5439b5a051cc138b6e12128264 ``` send `::1` as hostname? Even if we send a better error code, that is going to be a quite hard to debug incompatibility issue. Should we notify the openssl guys? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134699480 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 24 21:40:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 24 Jan 2019 20:40:07 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/issues/8083 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683#note_134714059 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:07:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:07:31 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) 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/891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:20:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:20:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Reassigned Issue 631 https://gitlab.com/gnutls/gnutls/issues/631 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:20:55 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:20:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: I'll add a check for guile-2.2 in `dist-hook` during the next release. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_134788539 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:25:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:25:23 +0000 Subject: [gnutls-devel] GnuTLS | priorities: when %NO_EXTENSIONS is specified disable TLS1.3 (!893) In-Reply-To: References: Message-ID: Merged manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/893#note_134789304 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:25:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:25:24 +0000 Subject: [gnutls-devel] GnuTLS | priorities: when %NO_EXTENSIONS is specified disable TLS1.3 (!893) In-Reply-To: References: Message-ID: Merge Request !893 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/893 Branches: tmp-define-no-extensions to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/893 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:26:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:26:34 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #631: https://gitlab.com/gnutls/gnutls/issues/631 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:28:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:28:07 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) 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/683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:28:22 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:28:22 +0000 Subject: [gnutls-devel] GnuTLS | Multiple issues with handling record_size_limit extension (#676) 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/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 Fri Jan 25 08:29:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:29:33 +0000 Subject: [gnutls-devel] GnuTLS | introduce a gitlab policy to automatically close bugs open for too long without resolution/action (#635) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/635 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:53:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:53:46 +0000 Subject: [gnutls-devel] GnuTLS | attempt for grooming: Items to be addressed in 3.6.6 (#634) In-Reply-To: References: Message-ID: Milestone removed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 08:58:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 07:58:13 +0000 Subject: [gnutls-devel] GnuTLS | Reconsidering use of VLAs and alloca() (#684) In-Reply-To: References: Message-ID: Are we using alloca? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684#note_134799078 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 09:02:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 08:02:20 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: This makes CI fail :( Unfortunately cannot check it further now; I'll move on with the release I'll try to check it tomorrow. https://gitlab.com/gnutls/gnutls/-/jobs/150973379 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_134800166 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 09:02:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:02:50 +0100 Subject: [gnutls-devel] gnutls 3.6.6 Message-ID: Hello, I've just released gnutls 3.6.6. This is a bug fix release on the 3.6.x branch. It introduces support for raw public keys, fixes several small issues and issues related to TLS1.3 support. I'd like to thank everyone who contributed in this release: Tim R?hsen, Daiki Ueno, Dmitry Eremin-Solenikov, Hugo Beauz?e-Luyssen, Peter Wu, Andreas Metzler, Fabrice Fontaine, Alon Bar-Lev, Maks Naumov, Marga Manterola and Tom Vrancken. The detailed list of changes follows; they can be seen in more detail in our milestone tracker: https://gitlab.com/gnutls/gnutls/milestones/18 Changes ======= * Version 3.6.6 (released 2019-01-25) ** libgnutls: gnutls_pubkey_import_ecc_raw() was fixed to set the number bits on the public key (#640). ** libgnutls: Added support for raw public-key authentication as defined in RFC7250. Raw public-keys can be negotiated by enabling the corresponding certificate types via the priority strings. The raw public-key mechanism must be explicitly enabled via the GNUTLS_ENABLE_RAWPK init flag (#26, #280). ** libgnutls: When on server or client side we are sending no extensions we do not set an empty extensions field but we rather remove that field competely. This solves a regression since 3.5.x and improves compatibility of the server side with certain clients. ** libgnutls: We no longer mark RSA keys in PKCS#11 tokens as RSA-PSS capable if the CKA_SIGN is not set (#667). ** libgnutls: The priority string option %NO_EXTENSIONS was improved to completely disable extensions at all cases, while providing a functional session. This also implies that when specified, TLS1.3 is disabled. ** libgnutls: GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION was marked as deprecated. The previous definition was non-functional (#609). ** API and ABI modifications: GNUTLS_ENABLE_RAWPK: Added GNUTLS_ENABLE_CERT_TYPE_NEG: Removed (was no-op; replaced by GNUTLS_ENABLE_RAWPK) GNUTLS_X509_NO_WELL_DEFINED_EXPIRATION: Deprecated GNUTLS_PCERT_NO_CERT: Deprecated Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.6.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.6.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From gnutls-devel at lists.gnutls.org Fri Jan 25 09:58:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 08:58:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-3.6.4 release tarball isn't configured for guile 2.2 (#631) In-Reply-To: References: Message-ID: On Fedora you need to install guile2 / guile22-devel. Our Fedora29 image just has guile 2.0. That's why it fails. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/631#note_134816402 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 10:05:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:05:04 +0000 Subject: [gnutls-devel] build-images | Add guile22-devel to Fedora29 (!18) References: Message-ID: New Merge Request !18 https://gitlab.com/gnutls/build-images/merge_requests/18 Branches: tmp-fedora29-guile22 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/18 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 10:22:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:22:07 +0000 Subject: [gnutls-devel] build-images | Add guile22-devel to Fedora29 (!18) In-Reply-To: References: Message-ID: Merge Request !18 was merged Merge Request url: https://gitlab.com/gnutls/build-images/merge_requests/18 Branches: tmp-fedora29-guile22 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/18 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 10:47:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:47:08 +0000 Subject: [gnutls-devel] GnuTLS | Reconsidering use of VLAs and alloca() (#684) In-Reply-To: References: Message-ID: - alloca() is used in the guile/src/core.c. The code around there looks very suspicious to me, it might need a review. E.g. it assumes that scm_to_locale_stringbuf() does not alter the byte-length of the input when it does charset transcoding. If that is the case, the output may be truncated and wouldn't work as credentials any more. - guarded VLA is ok as far as the limit isn't too high. But it needs manual checks when introducing new code. Just saying, that one is playing with fire when using VLAs. In your example, what are you going to do if n >= 128 ? Fallback to calloc() or throw an error ? I suggest to only use VLAs (if at all) when it comes to performance optimization. There is no urgent need, but in the long term... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684#note_134831843 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 10:54:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:54:47 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/ext/server_name.c: > DECR_LEN(data_size, len); > > if (type == 0) { /* NAME_DNS */ > - if (!_gnutls_dnsname_is_valid((char*)p, len)) > - return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + if (!_gnutls_dnsname_is_valid((char*)p, len)) { > + _gnutls_handshake_log > + ("HSK[%p]: Server name is not acceptable: '%.*s'\n", > + session, (int) len, p); > + return gnutls_assert_val(GNUTLS_E_UNRECOGNIZED_NAME); As @dueno pointed out in https://gitlab.com/gnutls/gnutls/issues/683#note_134637845, the standards demand `ILLEGAL_PARAMETER`. So I changed the return value back to `GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER` and just left the logging message in. It gives us an explanation what happened with `gnutls-serv -d 4`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_134834402 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 10:54:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 09:54:47 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: All discussions on Merge Request !891 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/891 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 11:06:08 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 10:06:08 +0000 Subject: [gnutls-devel] GnuTLS | WIP: prf: add function to retrieve early exporter secret (!894) References: Message-ID: New Merge Request !894 https://gitlab.com/gnutls/gnutls/merge_requests/894 Branches: tmp-early-exporter to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This adds a new function `gnutls_prf_rfc5705_early` to calculate early keying material. Fixes #329. ## 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/894 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 11:52:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 10:52:33 +0000 Subject: [gnutls-devel] GnuTLS | Fix unused var warning in guile/src/core.c (!895) References: Message-ID: New Merge Request !895 https://gitlab.com/gnutls/gnutls/merge_requests/895 Branches: tmp-fix-guile-unused-var 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 Trivial fix ## 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/895 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 12:20:26 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 11:20:26 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: This one was closed fast. @nmav you said most likely. So what version should I use to test the fix? I would prefer to give you feedback instead of creating a useless ticket :sweat\_smile: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_134861590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 12:28:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 11:28:30 +0000 Subject: [gnutls-devel] GnuTLS | Fix abi-check failure (!896) References: Message-ID: New Merge Request !896 https://gitlab.com/gnutls/gnutls/merge_requests/896 Branches: tmp-fix-abi-check 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 Using `./bootstrap` instead of `make autoreconf` for `make abi-check`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/896 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 18:12:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 17:12:20 +0000 Subject: [gnutls-devel] GnuTLS | Fix abi-check failure (!896) In-Reply-To: References: Message-ID: Merge Request !896 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/896 Branches: tmp-fix-abi-check to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/896 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 18:12:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 17:12:23 +0000 Subject: [gnutls-devel] GnuTLS | Fix abi-check failure (!896) In-Reply-To: References: Message-ID: Merge Request !896 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/896 Branches: tmp-fix-abi-check to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/896 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 18:14:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 17:14:51 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/ext/server_name.c: > DECR_LEN(data_size, len); > > if (type == 0) { /* NAME_DNS */ > - if (!_gnutls_dnsname_is_valid((char*)p, len)) > - return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + if (!_gnutls_dnsname_is_valid((char*)p, len)) { > + _gnutls_handshake_log > + ("HSK[%p]: Server name is not acceptable: '%.*s'\n", > + session, (int) len, p); > + return gnutls_assert_val(GNUTLS_E_UNRECOGNIZED_NAME); > As @dueno pointed out in https://gitlab.com/gnutls/gnutls/issues/683#note_134637845, the standards demand `ILLEGAL_PARAMETER`. So I changed the return value back to `GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER` and just left the logging message in. It gives us an explanation what happened with `gnutls-serv -d 4`. Note that the standards' requirements are on the alert returned to the peer. The error the application received is fully under our control. It is normal to return a descriptive error code to application and map it to a specific alert. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_135108701 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 19:54:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 18:54:05 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Check 3.6.6. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_135126608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jan 25 23:40:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 25 Jan 2019 22:40:00 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/ext/server_name.c: > DECR_LEN(data_size, len); > > if (type == 0) { /* NAME_DNS */ > - if (!_gnutls_dnsname_is_valid((char*)p, len)) > - return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + if (!_gnutls_dnsname_is_valid((char*)p, len)) { > + _gnutls_handshake_log > + ("HSK[%p]: Server name is not acceptable: '%.*s'\n", > + session, (int) len, p); > + return gnutls_assert_val(GNUTLS_E_UNRECOGNIZED_NAME); > It is normal to return a descriptive error code to application and map it to the specific alert the standard requires. That normally is my understanding, but in this case I wasn't sure. Then we should add another error as you suggest. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_135158614 You're receiving 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 Jan 26 08:02:29 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 07:02:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli --benchmark type overflow on 32 bit arch (#685) References: Message-ID: New Issue was created. Issue 685: https://gitlab.com/gnutls/gnutls/issues/685 Author: Andreas Metzler Assignee: ## Description of problem: On 32bit gnutls-cli --benchmark-ciphers produces wrong results. Same machine 64bit installation: ``` Checking ciphers, payload size: 16384 3DES-CBC 27.91 MB/sec AES-128-CBC 1.34 GB/sec SALSA20-256 0.62 GB/sec NULL 35.20 GB/sec ``` and 32bit chroot: ``` Checking ciphers, payload size: 16384 3DES-CBC 27.19 MB/sec AES-128-CBC 0.47 GB/sec SALSA20-256 0.39 GB/sec NULL 0.40 GB/sec ``` ## Version of gnutls used: 3.6.5, but it should be present in 3.6.6 also. ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian ## How reproducible: Always. Steps to Reproduce: * one Run gnutls-cli --benchmark-ciphers This was found and diagnosed by Hiroyuki YAMAMORI as https://bugs.debian.org/920477: > The following code is the cause. > >"gnutls-3.6.5/src/benchmark.h" line 45 ``` struct benchmark_st { struct timespec start; unsigned long size; <== 32bit in i386 arch. sighandler_t old_handler; #if defined(_WIN32) HANDLE wtimer; HANDLE wthread; LARGE_INTEGER alarm_timeout; #endif ``` >This size variable will overflow. -- 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 Sat Jan 26 08:46:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 07:46:56 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli --benchmark type overflow on 32 bit arch (#685) 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/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 Sat Jan 26 08:50:27 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 07:50:27 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Note that the 3.6.x series of gnutls enables TLS1.3 by default. If the error is not solved it can be some TLS1.3 server intolerance. You may want to re-open and attach a capture. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_135199802 You're receiving 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 Jan 26 08:58:14 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 07:58:14 +0000 Subject: [gnutls-devel] GnuTLS | TLS1.3 PSK: support PSK with SHA384 (#386) In-Reply-To: References: Message-ID: I think the rule is no new feature which is enabled by default. So, if there is a step needed for these keys (e.g., a different password file entry), or a flag to be set by the application should be ok. Do you have in mind an implementation? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/386#note_135200460 You're receiving 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 Jan 26 13:45:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 12:45:28 +0000 Subject: [gnutls-devel] GnuTLS | coverage drop (#550) In-Reply-To: References: Message-ID: It seems that `softhsm` was missing from our the fedora image that was doing the coverage calculation, and it dropped the coverage significantly. The coverage calculation is still very flaky though ranging from 74 to 76%, probably beause we run tests in parallel. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/550#note_135228869 You're receiving 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 Jan 26 13:45:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 12:45:28 +0000 Subject: [gnutls-devel] GnuTLS | coverage drop (#550) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #550: https://gitlab.com/gnutls/gnutls/issues/550 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/550 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jan 26 14:27:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 13:27:48 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Merge Request !891 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/891 Branches: tmp-fix-sni-error to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891 You're receiving 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 Jan 26 21:50:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 20:50:20 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/ext/server_name.c: > DECR_LEN(data_size, len); > > if (type == 0) { /* NAME_DNS */ > - if (!_gnutls_dnsname_is_valid((char*)p, len)) > - return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER); > + if (!_gnutls_dnsname_is_valid((char*)p, len)) { > + _gnutls_handshake_log > + ("HSK[%p]: Server name is not acceptable: '%.*s'\n", > + session, (int) len, p); > + return gnutls_assert_val(GNUTLS_E_UNRECOGNIZED_NAME); Added another commit to introduce GNUTLS_E_RECEIVED_UNRECOGNIZED_NAME. Please review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_135297728 You're receiving 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 Jan 26 21:56:18 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 26 Jan 2019 20:56:18 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) References: Message-ID: New Merge Request !897 https://gitlab.com/gnutls/gnutls/merge_requests/897 Branches: tmp-fix-uninitialized 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 an annoying warning (a false positive due to spaghetti code). My editor automatically removes trailing spaces, there were a few comment lines changes this way as well. ## 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/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 Sun Jan 27 08:42:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 07:42:46 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: @rockdaboot new `v3.6.6` does not have this issue? I can build `gnutls` without any errors. I'll close this issue if it is OK for you. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662#note_135334715 You're receiving 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 Jan 27 12:56:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 11:56:28 +0000 Subject: [gnutls-devel] GnuTLS | build: detect previous supported guile (!898) References: Message-ID: New Merge Request !898 https://gitlab.com/gnutls/gnutls/merge_requests/898 Project:Branches: alonbl/gnutls:guile to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/898 You're receiving 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 Jan 27 13:01:00 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 12:01:00 +0000 Subject: [gnutls-devel] GnuTLS | .gitignore: add test files (!899) References: Message-ID: New Merge Request !899 https://gitlab.com/gnutls/gnutls/merge_requests/899 Project:Branches: alonbl/gnutls:gitignore to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/899 You're receiving 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 Jan 27 18:19:43 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 17:19:43 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: @tanersener Good news :-) Then let's close the issue ! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662#note_135423440 You're receiving 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 Jan 27 18:21:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 17:21:45 +0000 Subject: [gnutls-devel] GnuTLS | .gitignore: add test files (!899) In-Reply-To: References: Message-ID: Merge Request !899 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/899 Project:Branches: alonbl/gnutls:gitignore to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/899 You're receiving 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 Jan 27 18:21:49 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 17:21:49 +0000 Subject: [gnutls-devel] GnuTLS | .gitignore: add test files (!899) In-Reply-To: References: Message-ID: Merge Request !899 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/899 Project:Branches: alonbl/gnutls:gitignore to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/899 You're receiving 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 Jan 27 18:23:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 17:23:50 +0000 Subject: [gnutls-devel] GnuTLS | build: detect previous supported guile (!898) In-Reply-To: References: Message-ID: Merge Request !898 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/898 Project:Branches: alonbl/gnutls:guile to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/898 You're receiving 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 Jan 27 18:23:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 17:23:53 +0000 Subject: [gnutls-devel] GnuTLS | build: detect previous supported guile (!898) In-Reply-To: References: Message-ID: Merge Request !898 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/898 Project:Branches: alonbl/gnutls:guile to gnutls/gnutls:master Author: Alon Bar-Lev Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/898 You're receiving 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 Jan 27 19:01:05 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 18:01:05 +0000 Subject: [gnutls-devel] GnuTLS | macOS compilation fails (#662) In-Reply-To: References: Message-ID: Issue was closed by Taner Sener Issue #662: https://gitlab.com/gnutls/gnutls/issues/662 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/662 You're receiving 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 Jan 27 19:23:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 18:23:48 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) References: Message-ID: New Issue was created. Issue 686: https://gitlab.com/gnutls/gnutls/issues/686 Author: Tim R?hsen Assignee: Right now fuzzing covers just 33.5% of GnuTLS code lines (40% function coverage). We should try to increase the coverage. How to display the fuzz coverage: ``` ./configure --disable-doc --enable-code-coverage make clean make make -C fuzz check make code-coverage-capture CODE_COVERAGE_IGNORE_PATTERN='*/include/* /home/tim/src/gnutls/gl/*' xdg-open file:///home/tim/src/gnutls/GnuTLS-3.6.6-coverage/index.html ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686 You're receiving 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 Jan 27 20:56:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 19:56:20 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Issue was reopened by Alfred Feldmeyer Issue 677: https://gitlab.com/gnutls/gnutls/issues/677 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677 You're receiving 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 Jan 27 20:58:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 19:58:50 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: Well sry Nikos, I just tested it with the following result: ``` ./gnutls-cli -V -p 443 vpn.domain.tld --debug=2 Processed 156 CA certificate(s). Resolving 'vpn.domain.tld:443'... Connecting to '123.123.123.123:443'... |<2>| added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list |<2>| Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384) |<2>| Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256) |<2>| Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256) |<2>| Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256) |<2>| Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384) |<2>| Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305) |<2>| Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM) |<2>| Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1) |<2>| Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256) |<2>| Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM) |<2>| Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1) |<2>| Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384) |<2>| Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305) |<2>| Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1) |<2>| Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256) |<2>| Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1) |<2>| Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384) |<2>| Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM) |<2>| Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) |<2>| Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256) |<2>| Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM) |<2>| Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1) |<2>| Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384) |<2>| Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305) |<2>| Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM) |<2>| Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) |<2>| Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256) |<2>| Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM) |<2>| Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) |<2>| Advertizing version 3.4 |<2>| Advertizing version 3.3 |<2>| Advertizing version 3.2 |<2>| Advertizing version 3.1 |<2>| HSK[0x1911da0]: sent server name: 'vpn.domain.tld' *** Fatal error: A TLS fatal alert has been received. *** Received alert [40]: Handshake failed ``` Is there anything I could to else? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_135434963 You're receiving 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 Jan 27 21:13:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 27 Jan 2019 20:13:40 +0000 Subject: [gnutls-devel] GnuTLS | TLS handshake used by openconnect/anyconnect fails after 3.5.18 (#677) In-Reply-To: References: Message-ID: here is the wireshark protocol to this command: ![image](/uploads/2e1b49207703c0e408fa8e2540d4ae42/image.png) (Just in case: Could you mark this issue as confidential? It's related to my company and I don't want to be kicked, in case I missed to blackout anything. Thx in advance) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/677#note_135436202 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 08:07:34 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 07:07:34 +0000 Subject: [gnutls-devel] GnuTLS | fuzzying: enable raw public keys (#687) References: Message-ID: New Issue was created. Issue 687: https://gitlab.com/gnutls/gnutls/issues/687 Author: Nikos Mavrogiannopoulos Assignee: ## Description of problem: Currently we have fuzzers for X509 keys/certificates but not for raw public keys. If we'd like both code bases to be in par in terms of quality we should enable fuzzying for raw public keys as well (see `gnutls_client_fuzzer`, `gnutls_server_fuzzer` and `README-adding-traces` for more info). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/687 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 08:08:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 07:08:07 +0000 Subject: [gnutls-devel] GnuTLS | fuzzying: enable raw public keys (#687) In-Reply-To: References: Message-ID: @Vrancken would you like to check this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/687#note_135507481 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 08:08:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 07:08:40 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: Is there some way to display that coverage in our README.md? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_135507559 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 10:32:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 09:32:11 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: We can deploy any files/directories to https://gnutls.gitlab.io/gnutls from a CI runner. And then link to there from README.md. Is that acceptable ? As example see https://gitlab.com/libidn/libidn2 (search for "coverage of our fuzzers" and click on 'here'). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_135547105 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 13:46:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 12:46:36 +0000 Subject: [gnutls-devel] GnuTLS | Fix unused var warning in guile/src/core.c (!895) In-Reply-To: References: Message-ID: Merge Request !895 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/895 Branches: tmp-fix-guile-unused-var to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/895 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 13:46:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 12:46:42 +0000 Subject: [gnutls-devel] GnuTLS | Fix unused var warning in guile/src/core.c (!895) In-Reply-To: References: Message-ID: Merge Request !895 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/895 Branches: tmp-fix-guile-unused-var to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/895 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 15:26:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 14:26:50 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) References: Message-ID: New Merge Request !900 https://gitlab.com/gnutls/gnutls/merge_requests/900 Branches: tmp-update-glimport-and-docs 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 glimport and the text in CONTRIBUTING.md seemed to be outdated. ## 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/900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 16:36:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 15:36:53 +0000 Subject: [gnutls-devel] GnuTLS | WIP: prf: add function to retrieve early keying material (!894) In-Reply-To: References: Message-ID: While I think the functionality itself now works, I am not sure if this is sufficient for the practical use in QUIC. The early keying material is calculated using a transcript hash of ClientHello, and there is no way to export it in a timely manner (as handshake hook is called *before* we can calculate the early master secret). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/894#note_135688627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jan 28 22:40:48 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 28 Jan 2019 21:40:48 +0000 Subject: [gnutls-devel] GnuTLS | fuzzying: enable raw public keys (#687) In-Reply-To: References: Message-ID: I'll look into it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/687#note_135803316 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 08:35:51 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 07:35:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: prf: add function to retrieve early keying material (!894) In-Reply-To: References: Message-ID: What would be your suggestion for addressing that? Adding a new hook htype? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/894#note_135924055 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 08:39:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 07:39:20 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: It sounds like a good idea. We already have the `coverage` project, we could introduce the `fuzzer-coverage` or so and make a badge from the coverage calculated by it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_135924733 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 09:22:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 08:22:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: prf: add function to retrieve early keying material (!894) In-Reply-To: References: Message-ID: That would be an option. Alternatively, we can calculate the secret in `_gnutls_send_handshake` immediately after the transcript hash is updated. That would allow both client and server to just hook `GNUTLS_HANDSHAKE_CLIENT_HELLO`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/894#note_135935550 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 11:03:47 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 10:03:47 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: I took a look at the coverage project, seems straight forward. We could also add the coverage (and fuzz-coverage) to gnutls CI - it wouldn't cost anything when we integrate it into the 'abi/coverage' runner. And it would update with every commit (we can limit it to each commit to master). ``` ... - make local-code-coverage-output || true - rm -rf GnuTLS-*-coverage GnuTLS-*-coverage.info - make -C fuzz check - make code-coverage-capture CODE_COVERAGE_IGNORE_PATTERN='*/include/* /home/tim/src/gnutls/gl/*' - mv GnuTLS-*-coverage public/fuzz-coverage artifacts: when: on_success paths: - public/fuzz-coverage ``` This only takes a few seconds. Since Gitlab can't create two badges, we can create our own badge e.g. with ``` wget -Opublic/fuzz-coverage/badge.svg https://img.shields.io/badge/fuzz--coverage-31.9-red.svg ``` We can also directly generate an SVG, it's just a small text file. I'll have to read about the details... It's easier as maintaining a second project and we stay independent of Gitlab.com. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_135989064 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 13:28:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 12:28:20 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: gitlab doesn't do much with the coverage results anyway (doesn't require the coverage to be increased nor shows the change), thus I do not see a benefit in adding it in CI. Having the badge with the coverage calculated from the other fuzzer project would be fine IMHO. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136045745 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 14:02:46 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 13:02:46 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Thanks for discovering that; it looks pretty complex code. Even with that fix there may be an error later at: ``` ((char *) output)[len] = '\0'; ``` I couldn't completely exclude that this may happen. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_136074407 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 14:19:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 13:19:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on CONTRIBUTING.md: > > # Gnulib > > -The files at `gl/`, `src/gl/` and `lib/unistring` directories are part of > -gnulib project and are included mainly for systems which may miss functionality > -available in glibc and unistring libraries. These files are updated when new > -functionality is needed or bug fixes affecting gnutls are required. > +The directories `gl/`, `src/gl/` and `lib/unistring` contain gnulib files > +copied/created by `./bootstrap`. Gnulib is a portability source code library > +to handle API or behavior incompatibilities between target systems. > > -They can be updated by the following make rule. > +To take advantage of the latest gnulib files, we have to update the > +`gnulib/` submodule from time to time: Do we need that rule at all now with bootstrap? (i.e., why not say re-run bootstrap locally)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136080146 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 14:21:35 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 13:21:35 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on CONTRIBUTING.md: > > # Gnulib > > -The files at `gl/`, `src/gl/` and `lib/unistring` directories are part of > -gnulib project and are included mainly for systems which may miss functionality > -available in glibc and unistring libraries. These files are updated when new > -functionality is needed or bug fixes affecting gnutls are required. > +The directories `gl/`, `src/gl/` and `lib/unistring` contain gnulib files > +copied/created by `./bootstrap`. Gnulib is a portability source code library > +to handle API or behavior incompatibilities between target systems. > > -They can be updated by the following make rule. > +To take advantage of the latest gnulib files, we have to update the > +`gnulib/` submodule from time to time: Seeing the change below, I didn't understand the text here. What I understood is that the gnulib will be updated locally with the latest. What I think it is done is that the gnulib used by the project is updated to the latest upstream, and the result is committed to the repo. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136081103 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 14:50:37 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 13:50:37 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: > Do we need the glimport rule at all now with bootstrap? IMO we don't need `glimport` at all, we can also document the little set of commands executed by `make glimport`. But then I didn't want to be too intrusive. Maybe someone is used to use glimport - why breake it without need ? > and the result is committed to the repo Not really, what we commit to the gnutls repo is just the gnulib (submodule) commit ID. To really pull in the gnulib upstream files you need `git submodule init/update` commands. These are automatically called by `./bootstrap`. The next step is to call gnulib-tool: it fills the directories `gl/`, `src/gl/` and `lib/unistring`. The details are also handled by `./bootstrap`. It doesn't matter if you have a local gnulib repository or not and if that is up-to-date or not. `./bootstrap` just does "the right thing". It tries to find the gnulib submodule commit ID in your local gnulib repo plus all the files. If that doesn't work out, it pulls them in from upstream into gnutls/gnulib. IMO, we shouldn't document all these details. Just saying `./bootstrap` cares about the gory details should be enough. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136091544 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 15:04:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 14:04:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Why ? `len` is explicitly set in all code paths just some lines before: ``` if (temp_str) len = strlen(temp_str); else if (str_max == 0) len = 0; else len = p11_kit_space_strlen(str, str_max); ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_136096446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 16:13:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 15:13:28 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Just pushed an alternative branch `tmp-fix-uninitialized2` that also makes some code cleanups. IMO that is better readable. Feel free to remove this MR and create a new one with the new branch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_136129605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 16:32:30 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 15:32:30 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: The advantage is that we don't need to maintain another project just for the coverage output. I created a 'make-coverage-badge' script and all to libidn2. Just as an example how easy it is. See the fuzz-coverage badge at https://gitlab.com/libidn/libidn2. The commit with the things tied together is https://gitlab.com/libidn/libidn2/commit/530c929434bcbe2fa713827af1b171001c7e4d87. The green is a bit lighter than we are used to. It's "lawngreen" instead of some fancy RGB hex values. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136140245 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 16:33:25 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 15:33:25 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: > Having the badge with the coverage calculated from the other fuzzer project What exactly is that ? tlsfuzzer ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136140764 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 17:20:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 16:20:06 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: Sorry I meant the coverage project. It has a badge and this is what is now shown in the gnutls main page(top) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136159170 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jan 29 20:37:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 29 Jan 2019 19:37:20 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: Then let me summarize my current understanding: - we don't generate the fuzz-coverage-badge from the standard CI - we don't generate the fuzz-coverage-badge from it's own project - we extend project `gnutls/coverage` with the `make-coverage-badge` script and put it plus the fuzz-coverage pages into `public/fuzz-coverage/`, add the badge to (gnutls's) `README.md` to access https://gnutls.gitlab.io/coverage/fuzzing/index.html (or a similar named directory). Please ACK if that is OK to you and give me developer access to the coverage project. Then I can care about it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136226799 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 08:13:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 07:13:50 +0000 Subject: [gnutls-devel] GnuTLS | Increase fuzzing code coverage (#686) In-Reply-To: References: Message-ID: - we don't generate the fuzz-coverage-badge from the standard CI (generated daily) - we don't generate the fuzz-coverage-badge from it's own project - we extend project `gnutls/coverage` with the `make-coverage-badge` script and put it plus the fuzz-coverage pages into `public/fuzz-coverage/`, add the badge to (gnutls's) badges list (shows on top of project page). We could also add it to `README.md` to access https://gnutls.gitlab.io/coverage/fuzzing/index.html (or a similar named directory). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/686#note_136347342 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 08:20:20 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 07:20:20 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Merge Request !897 was approved by Nikos Mavrogiannopoulos 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 Wed Jan 30 08:20:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 07:20:52 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: You're right. It seem I got confused. I have not see the other version yet. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_136348731 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 08:25:31 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 07:25:31 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: > IMO we don't need `glimport` at all, we can also document the little set of commands executed by `make glimport`. But then I didn't want to be too intrusive. Maybe someone is used to use glimport - why break it without need ? I think the target group for the functionality at hand is the ones who update gnulib and that's me and you in this project for the last 3 years. Having it there as a documented shortcut to switching the gnulib to the latest upstream makes sense, but keeping it for compatibility seems unnecessary to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136349699 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 09:13:09 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 08:13:09 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (!897) In-Reply-To: References: Message-ID: Here you can see my suggestion: https://gitlab.com/gnutls/gnutls/commit/2063c6193af6653175e6bc073babea607e5b0ff4 If you are ok with it, I'll create a MR to replace this one. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/897#note_136373718 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 09:44:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 08:44:33 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: > We can remove it the same way as we removed make autoreconf, but my preference would be to have it as a shortcut that updates gnulib to the latest upstream. That is what this commit/MR does. I am a bit puzzled right now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136383703 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 11:19:24 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 10:19:24 +0000 Subject: [gnutls-devel] GnuTLS | Reconsidering use of VLAs and alloca() (#684) In-Reply-To: References: Message-ID: Another reason to use malloc()/heap instead of VLA/stack is that sanitizers/fuzzing have difficulties to detect buffer overflows on the stack. Mainly because local variables are put together as one single block of stack memory. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/684#note_136465853 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 14:14:56 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 13:14:56 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: > IMO, we shouldn't document all these details. Just saying `./bootstrap` cares about the gory details should be enough. I was mostly re-acting to the above text; I read it as keeping glimport but not documenting it. Sorry if I caused more confusion. I think it would be good to keep glimport and document it in the `CONTRIBUTION` text. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136554703 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 14:27:13 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 13:27:13 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (2063c619) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/pkcs11.c: > > - if (temp_str) > - len = strlen(temp_str); > - else if (str_max == 0) > - len = 0; > - else > - len = p11_kit_space_strlen(str, str_max); > - > - if (len + 1 > *output_size) { > + if (len < *output_size) { > + if (len) > + memcpy(output, str, len); > + ((char *) output)[len] = '\0'; > + *output_size = len; > + ret = 0; > + } else { It looks good to me (the whole cleanup), but I'd feel safer if we added a test case to check for this particular error code before merging this clean this up. Seeing [the coverage of this file](https://gnutls.gitlab.io/coverage/master/builds/gnutls/coverage/gnutls-git/lib/pkcs11.c.gcov.html), it seems that the error case of `GNUTLS_E_SHORT_MEMORY_BUFFER` is not tested; and this function has no unit test (tested via p11tool's use only). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/2063c6193af6653175e6bc073babea607e5b0ff4#note_136560731 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:20:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:20:53 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: So guys, can i conclude that at this moment, 2019-01-30T15:20:32+01:00,this library is incapable of being used with custom I/O? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_136592136 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:40:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:40:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (2063c619) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/pkcs11.c: > > - if (temp_str) > - len = strlen(temp_str); > - else if (str_max == 0) > - len = 0; > - else > - len = p11_kit_space_strlen(str, str_max); > - > - if (len + 1 > *output_size) { > + if (len < *output_size) { > + if (len) > + memcpy(output, str, len); > + ((char *) output)[len] = '\0'; > + *output_size = len; > + ret = 0; > + } else { I see. But we currently don't have a test that we can easily extend. The function is called during the tests only indirectly from p11tool. IMO we should have a fuzzer for the gnutls_pkcs11 API. But that is definitely a different issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/2063c6193af6653175e6bc073babea607e5b0ff4#note_136602212 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:40:17 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:40:17 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: No, that's clearly wrong. We've been using it in a single-threaded [DNS resolver](https://knot-resolver.cz) with [libuv](https://libuv.org) I/O all the time – mainly for DNS-over-TLS, both client and server side. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_136602236 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:43:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:43:28 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: But I didn't remove it and what it does is (still) documented in `CONTRIBUTING.md`. What exactly is missing ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136603302 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:56:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:56:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: Then it seems I caused more confusion based on mine. Sorry for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900#note_136607852 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:56:32 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:56:32 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: All discussions on Merge Request !900 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/900 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:57:07 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:57:07 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: All discussions on Merge Request !900 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/900 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 15:57:38 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 14:57:38 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: Merge Request !900 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/900 Branches: tmp-update-glimport-and-docs to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 16:02:33 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 15:02:33 +0000 Subject: [gnutls-devel] GnuTLS | Fix uninitialized warning in pkcs11.c (2063c619) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/pkcs11.c: > > - if (temp_str) > - len = strlen(temp_str); > - else if (str_max == 0) > - len = 0; > - else > - len = p11_kit_space_strlen(str, str_max); > - > - if (len + 1 > *output_size) { > + if (len < *output_size) { > + if (len) > + memcpy(output, str, len); > + ((char *) output)[len] = '\0'; > + *output_size = len; > + ret = 0; > + } else { `tests/pkcs11/pkcs11-token-raw.c` seems like it be extended (or serve as basis for another a unit test). It loads the module described in `tests/pkcs11/pkcs11-mock.h`. We can check pretty much all options except `GNUTLS_PKCS11_TOKEN_MODNAME`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/commit/2063c6193af6653175e6bc073babea607e5b0ff4#note_136610418 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 19:07:28 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 18:07:28 +0000 Subject: [gnutls-devel] GnuTLS | use custom transport with gnutls (#673) In-Reply-To: References: Message-ID: The description of the loop you get isn't very clear to me, but it kind of sounds like a non-blocking send or receive operation is retried immediately (leading to the endless loop) instead of giving other operations a chance to run first. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/673#note_136671435 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 20:00:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 19:00:04 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: replace nettle-stdint.h with just stdint.h (!901) References: Message-ID: New Merge Request !901 https://gitlab.com/gnutls/gnutls/merge_requests/901 Project:Branches: GostCrypt/gnutls:nettle-stdint 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/901 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 22:08:01 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 21:08:01 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: replace nettle-stdint.h with just stdint.h (!901) In-Reply-To: References: Message-ID: Merge Request !901 was approved by Tim R?hsen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/901 Project:Branches: GostCrypt/gnutls:nettle-stdint 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/901 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 22:11:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 21:11:04 +0000 Subject: [gnutls-devel] GnuTLS | Fix 'make glimport' and update CONTRIBUTING.md (!900) In-Reply-To: References: Message-ID: Merge Request !900 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/900 Branches: tmp-update-glimport-and-docs to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jan 30 22:32:21 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 30 Jan 2019 21:32:21 +0000 Subject: [gnutls-devel] GnuTLS | lib/nettle: replace nettle-stdint.h with just stdint.h (!901) In-Reply-To: References: Message-ID: Merge Request !901 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/901 Project:Branches: GostCrypt/gnutls:nettle-stdint 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/901 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 08:58:06 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 07:58:06 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/alert.c: > case GNUTLS_E_ILLEGAL_SRP_USERNAME: > case GNUTLS_E_PK_INVALID_PUBKEY: > case GNUTLS_E_UNKNOWN_COMPRESSION_ALGORITHM: > + case GNUTLS_E_RECEIVED_UNRECOGNIZED_NAME: what about `malformed` instead of unrecognized? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_136850802 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:02:42 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:02:42 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Except for the suggestion above it looks good to me. This breaks expectations from the library in terms of expected errors, but do not think that this breakage is significant; there is no way to recover from the previous error, and many other conditions were bundled in the previous error code. I think it is fine to include in 3.6.7. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_136851793 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:09:04 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:09:04 +0000 Subject: [gnutls-devel] GnuTLS | WIP: prf: add function to retrieve early keying material (!894) In-Reply-To: References: Message-ID: Sounds good too. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/894#note_136853342 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:12:39 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:12:39 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/alert.c: > case GNUTLS_E_ILLEGAL_SRP_USERNAME: > case GNUTLS_E_PK_INVALID_PUBKEY: > case GNUTLS_E_UNKNOWN_COMPRESSION_ALGORITHM: > + case GNUTLS_E_RECEIVED_UNRECOGNIZED_NAME: maybe `disallowed` or `forbidden` is more precise !? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_136854382 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:12:50 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:12:50 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/alert.c: > case GNUTLS_E_ILLEGAL_SRP_USERNAME: > case GNUTLS_E_PK_INVALID_PUBKEY: > case GNUTLS_E_UNKNOWN_COMPRESSION_ALGORITHM: > + case GNUTLS_E_RECEIVED_UNRECOGNIZED_NAME: also fine! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_136854436 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:34:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:34:36 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on lib/alert.c: > case GNUTLS_E_ILLEGAL_SRP_USERNAME: > case GNUTLS_E_PK_INVALID_PUBKEY: > case GNUTLS_E_UNKNOWN_COMPRESSION_ALGORITHM: > + case GNUTLS_E_RECEIVED_UNRECOGNIZED_NAME: Update pushed -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891#note_136862255 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 09:34:36 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 08:34:36 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: All discussions on Merge Request !891 were resolved by Tim R?hsen https://gitlab.com/gnutls/gnutls/merge_requests/891 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 10:34:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 09:34:52 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) References: Message-ID: New Issue was created. Issue 688: https://gitlab.com/gnutls/gnutls/issues/688 Author: Tim R?hsen Assignee: size_t and ssize_t are POSIX (https://pubs.opengroup.org/onlinepubs/009696799/basedefs/sys/types.h.html). So I wonder if we need the checks in configure.ac and the code in gnutls.h.in. Is it really the responsibility of `gnutls.h` to define `size_t` ? If you have a software project that includes headers like `gnutls.h` you should define `size_t` by yourself and *have it consistent everywhere in your system*. What we could use (if needed at all) is AC_TYPE_SIZE_T and AC_TYPE_SSIZE_T to make sure we have both types. This moves the responsibility of defining proper types away from GnuTLS itself. It's a question where we draw the line. -- 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 Thu Jan 31 12:08:19 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 11:08:19 +0000 Subject: [gnutls-devel] GnuTLS | Remove checks for ssize_t in configure.ac (#688) In-Reply-To: References: Message-ID: I think the more we simplify/remove unnecessary code the better. I do not think we require POSIX explicitly (we still run on windows), but if every system we care has it, let's do it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/688#note_136952470 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 12:55:52 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 11:55:52 +0000 Subject: [gnutls-devel] GnuTLS | Amend error code when SNI name is not accepted (!891) In-Reply-To: References: Message-ID: Merge Request !891 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/891 Branches: tmp-fix-sni-error to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 12:55:53 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 11:55:53 +0000 Subject: [gnutls-devel] GnuTLS | OpenSSL IPv6 PSK Incompatibility (#683) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #683: https://gitlab.com/gnutls/gnutls/issues/683 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/683 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 17:07:23 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 16:07:23 +0000 Subject: [gnutls-devel] GnuTLS | Fix issues in record_size_limit extension handling (!879) In-Reply-To: References: Message-ID: I think I have managed to address all the issues (except 2) in #676. Removing WIP. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137082745 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:27:40 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:27:40 +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/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); test case for that? it should be fairly easy to do that in tlsfuzzer (though it will require manually encoding the max_fragment_length) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137184263 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:37:11 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:37:11 +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 < 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'm not sure how that helps... so the client advertises that it can handle, say 2^12 B long records, but we have memory to send 2^10 records at most, why then should we _not_ negotiate the extension when the client will have no problem accepting our small 2^10 B records? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137186063 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:37:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:37:15 +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 < 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; the comment was correct - if the new_size is bigger than the MAX_RECORD_SIZE, then the agreed upon value *is* the max record size (it may change in the future when new extensions allow negotiating values above 2^14, but it's not the case now) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137186072 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:39:58 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:39:58 +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/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); there's no doc string in the function so I don't know what's the use case, but the name strongly suggest that the max_record_recv_size should not be taken into account for this calculation... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137186608 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:41:15 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:41:15 +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/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); the function is missing doc string, so I don't know what's its purpose, but the name strongly suggest that the max_record_recv_size shouldn't be taken into account here... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137186854 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jan 31 20:44:45 2019 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 31 Jan 2019 19:44:45 +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 < 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); I don't think it should be ignored, it should be clamped to MAX_RECORD_SIZE -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/879#note_137187505 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: