Proposed vote: Drop support for "passwd -crypt"
The OTC recently adopted a list of technical items still to be done which included this item: - Proposal: drop passwd -crypt (OMC vote required) The passwd application contains the option "-crypt" which provides an implementation for the traditional UNIX password encryption scheme based on a modified version of DES. This is a default option for the passwd application. The OTC recommendation is to drop support for this option from 3.0. Since this is the removal of a feature OMC approval is required. This is my proposed vote text "Drop from 3.0 support for the '-crypt' option from the passwd application" Feedback please on the proposed vote text before I raise this. Matt
Re: Additional things for deprecation
Hmmm, are we going to start marking types for deprecation? I would advise against it on a general level, 'cause that's likely to cause an implosion. See for example marking ENGINE for deprecation, i.e. this: diff --git a/include/openssl/types.h b/include/openssl/types.h index ee024cef29..4e73c0dc0d 100644 --- a/include/openssl/types.h +++ b/include/openssl/types.h @@ -172,7 +172,9 @@ typedef struct ossl_init_settings_st OPENSSL_INIT_SETTINGS; typedef struct ui_st UI; typedef struct ui_method_st UI_METHOD; -typedef struct engine_st ENGINE; +# ifndef OPENSSL_NO_DEPRECATED_3_0 +OSSL_DEPRECATEDIN_3_0 typedef struct engine_st ENGINE; +# endif typedef struct ssl_st SSL; typedef struct ssl_ctx_st SSL_CTX; Try that and see your build become... interesting. Cheers, Richard On Tue, 13 Oct 2020 11:40:37 +0200, Tim Hudson wrote: > > In a 3.0 context, EVP_PKEY_ASN1_METHOD and all the associated functions > should be marked > deprecated in my view. > > Tim. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality
As defined by the [OTC Voting Procedures][0], I am declaring the vote closed, as the number of uncast votes cannot affect the outcome of the vote. The vote is accepted. topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Proposed by Matt Caswell Public: yes opened: 2020-10-08 closed: 2020-10-13 accepted: yes (for: 8, against: 1, abstained: 1, not voted: 1) Matt [+1] Mark [ 0] Pauli [+1] Viktor [ ] Tim[+1] Richard[+1] Shane [-1] Tomas [+1] Kurt [+1] Matthias [+1] Nicola [+1] -- Nicola [0]: https://www.openssl.org/policies/omc-bylaws.html
Re: Alpha releases
On 07/10/2020 17:36, Matt Caswell wrote: > This vote has now started. I'll post here with the results once its > complete. This vote has now closed and was accepted: +1: 6: 0: 0 -1: 0 No vote: 1 Matt > > Matt > > On 06/10/2020 13:12, Matt Caswell wrote: >> The OTC meeting today discussed making further alpha releases while we >> continue to work towards getting to beta 1. It was proposed that we >> release alpha 7 on Thursday 15h October and then regularly on a 3 weekly >> basis thereafter until such time as beta 1 is ready. >> >> This will need to be an OMC decision so this is my suggested vote wording: >> >> "OpenSSL 3.0 Alpha 7 shouuld be released on Thursday 15th October and >> subsequent alpha releases should be performed on a 3 weekly basis until >> beta 1 is ready" >> >> I'd like to give an opportunity for feedback on the above before I call >> this vote. >> >> Note that the OTC discussions on beta 1 (looking at the proposal that >> Nicola posted to this list last Friday) are still ongoing. There will be >> a further meeting tomorrow. >> >> Matt >> >
Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality
+1 On Thu, 08 Oct 2020 16:27:18 +0200, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Technical Items still to be done
I have just close this vote. The final result was: accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) Matt On 08/10/2020 15:47, Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >- Anything that isn’t available must be put to an OTC vote to exclude. >- The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. >- Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. >- There might be some others. >- Review for exceptions. >- The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) >- Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) >- Need a list of things we know are not present - including things we > have > removed. >- We need to have mapping tables for various d2i/i2d functions. >- We need to have a mapping table from “old names” for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to >the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] >
Re: VOTE: Technical Items still to be done
+1 As for "EVP is the recommended API", I hope that everyone understands this to be for crypto functionality (hash functions, cipher functions, EVP_PKEY functions, MAC functions, KDF functions), not *everything*. On Thu, 08 Oct 2020 16:47:18 +0200, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >- Anything that isn’t available must be put to an OTC vote to exclude. >- The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. >- Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. >- There might be some others. >- Review for exceptions. >- The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) >- Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) >- Need a list of things we know are not present - including things we > have > removed. >- We need to have mapping tables for various d2i/i2d functions. >- We need to have a mapping table from “old names” for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to >the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [ ] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
Cancel that, wrong vote. For this, 0 On Tue, 13 Oct 2020 10:09:12 +0200, Richard Levitte wrote: > > +1 > > On Fri, 09 Oct 2020 14:02:29 +0200, > Tomas Mraz wrote: > > > > topic: The PR #11359 (Allow to continue with further checks on > > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > > As the change is borderline on bug fix/behaviour change OTC needs > > to decide whether it is acceptable for 1.1.1 branch. > > Proposed by Tomas Mraz > > Public: yes > > opened: 2020-10-09 > > closed: 2020-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [ ] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim[ ] > > Richard[ ] > > Shane [ ] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [ ] > > > > -- > > Tomáš Mráz > > No matter how far down the wrong road you've gone, turn back. > > Turkish proverb > > [You'll know whether the road is wrong if you carefully listen to your > > conscience.] > > > > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released
+1 On Fri, 09 Oct 2020 14:00:00 +0200, Nicola Tuveri wrote: > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 >and until 3.0 beta1 is released, in lieu of the weekly "developer >meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
+1 On Fri, 09 Oct 2020 14:02:29 +0200, Tomas Mraz wrote: > > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim[ ] > Richard[ ] > Shane [ ] > Tomas [+1] > Kurt [ ] > Matthias [ ] > Nicola [ ] > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
