Re: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.
We discussed that within the call. We did not add the 'optional' word because the meaning of it is convoluted with the parameter being really optional (as in fn(a, b, ...)). That the caller can pass NULL as OSSL_PARAM array pointer is already implicit. On Tue, 2021-02-02 at 11:28 +, Dr. Matthias St. Pierre wrote: > +1 > > I recall that in our discussion the OSSL_PARAM array pointer was > intended to be optional, > i.e., NULL pointers allowed. Maybe the word 'optional' should be > added as follows? > >EVP init functions should accept an *optional* OSSL_PARAM array to > set parameters. > > > > -Original Message- > > From: openssl-project On > > Behalf Of Dr Paul Dale > > Sent: Tuesday, February 2, 2021 10:18 AM > > To: openssl-project@openssl.org > > Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM > > array to set parameters. > > > > topic: EVP init functions should accept an OSSL_PARAM array to set > > parameters. > > comment: This will mostly avoid calling the equivalent set_param > > call. > > Proposed by pauli. > > Public: yes > > opened: 2020-02-02 > > closed: 2020-02-02 > > accepted: yes (for: 8, against: 0, abstained: 1, not voted: 2) -- 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.]
RE: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.
+1 I recall that in our discussion the OSSL_PARAM array pointer was intended to be optional, i.e., NULL pointers allowed. Maybe the word 'optional' should be added as follows? EVP init functions should accept an *optional* OSSL_PARAM array to set parameters. > -Original Message- > From: openssl-project On Behalf Of Dr > Paul Dale > Sent: Tuesday, February 2, 2021 10:18 AM > To: openssl-project@openssl.org > Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to > set parameters. > > topic: EVP init functions should accept an OSSL_PARAM array to set > parameters. > comment: This will mostly avoid calling the equivalent set_param call. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted: yes (for: 8, against: 0, abstained: 1, not voted: 2) smime.p7s Description: S/MIME cryptographic signature
RE: OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects
+1 > -Original Message- > From: openssl-project On Behalf Of Dr > Paul Dale > Sent: Tuesday, February 2, 2021 10:07 AM > To: openssl-project@openssl.org > Subject: OTC VOTE: functions not conforming to the TYPE_NAME_action_name > naming scheme are defects > > topic: Where a function does not use the TYPE_NAME_action_name naming > scheme, > it is considered to be a defect. > comment: These are not considered blockers for 3.0 if the function > existed in > 1.1.1. New functions that do not conform must be fixed before > release. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted: yes (for: 5, against: 0, abstained: 3, not voted: 3) smime.p7s Description: S/MIME cryptographic signature
OTC vote: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but not an EVP_xxx_CTX_copy call.
topic: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but not an EVP_xxx_CTX_copy call. comments: Existing EVP_xxx_copy() functions not to be removed in the 3.0 timeframe. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3)
OTC Vote: We should not support EVP_xxx_reset() operations.
topic: We should not support EVP_xxx_reset() operations. comment: The existing EVP_xxx_dup() function supports this functionality. Existing EVP_xxx_reset() functions not to be removed in the 3.0 timeframe. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 7, against: 0, abstained: 1, not voted: 3)
OTC Vote: EVP_MAC_init should accept key and key length arguments.
topic: EVP_MAC_init should accept key and key length arguments. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 4, against: 1, abstained: 4, not voted: 2)
OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.
topic: EVP init functions should accept an OSSL_PARAM array to set parameters. comment: This will mostly avoid calling the equivalent set_param call. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 8, against: 0, abstained: 1, not voted: 2)
OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects
topic: Where a function does not use the TYPE_NAME_action_name naming scheme, it is considered to be a defect. comment: These are not considered blockers for 3.0 if the function existed in 1.1.1. New functions that do not conform must be fixed before release. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 5, against: 0, abstained: 3, not voted: 3)
RE: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names.
+1 > -Original Message- > From: openssl-project On Behalf Of Dr > Paul Dale > Sent: Tuesday, February 2, 2021 9:52 AM > To: openssl-project@openssl.org > Subject: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for > function names. > > topic: Moving forwards we will use TYPE_NAME_action_name for function names. > comment: Not camel case, underscores separating words. I.e. EVP_MAC_update > not EVP_MACUpdate or EVP_MAC_Update. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted: yes (for: 7, against: 0, abstained: 1, not voted: 3) smime.p7s Description: S/MIME cryptographic signature
OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names.
topic: Moving forwards we will use TYPE_NAME_action_name for function names. comment: Not camel case, underscores separating words. I.e. EVP_MAC_update not EVP_MACUpdate or EVP_MAC_Update. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted: yes (for: 7, against: 0, abstained: 1, not voted: 3)
