Re: OSSL_PARAMs

I presume the reference approach was used to solve the issue of who actually owns/free's the data. > On 5 Jun 2019, at 9:18 am, Dr Paul Dale wrote: > > Shane’s major complaints are about the indirection the OSSL_PARAM structure > forces — for integers and return lengths and the necessity of

Re: OSSL_PARAMs

The controls are easier to understand and use currently. The advantage of params is that you can batch them, so that the order no longer matters during setup (e.g- I need to set EVP_MD first). The params are not being used in anger yet. My main problem with the params is that no data is set into

Re: proposed change to committers policy

It doesn’t stop us both reviewing a PR. That doesn’t mean we both need to approve. > On 24 May 2019, at 7:21 pm, Matthias St. Pierre > wrote: > > > > > In considering approvals, the combined approvals must come > > from individuals who work for separate organisations. > >

Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM. In OpenSSL_111 they were stripped down to do almost nothing i.e:- int FIPS_mode(void) { /* This version of the library does not support FIPS mode. */ return 0; } int FIPS_mode_set(int

Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked?

With the new architecture changes there are quite a few new calls to CRYPTO_UP_REF() CRYPTO_DOWN_REF() These methods return an int that is not being checked in lots of places. This return value only seems to affect fallback code that calls CRYPTO_atomic_add (which can return 0 on lock or

Re: Deprecations

> On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni > wrote: > > But there's nothing like > using a screwdriver to turn a screw, rather than banging it in with > an all-purpose hammer! If we are trying to tell users to not use the low level API’s, and then we go and use them everywhere in apps it

Re: CI build timeouts

Disabling memory leak checking doesn’t sound like a great idea.. > On 31 Mar 2020, at 1:09 am, Salz, Rich wrote: > > It’s time to disable that build, isn’t it? > It’s timing out *AFTER AN HOUR* > > From: Tomáš Mráz mailto:notificati...@github.com>> > Reply-To: openssl/openssl >

Re: OpenSSL version 3.0.0-alpha1 published

Thanks.. I will take a look. Shane > On 2 May 2020, at 2:20 am, Guido Vranken wrote: > > Reminder that in git master and 3.0.0, CAST5 gives the wrong output: > https://github.com/openssl/openssl/issues/11459 >

Reordering new API's that have a libctx, propq

PR #12778 reorders all the API’s of the form: EVP_XX_fetch(libctx, algname, propq) So that the algorithm name appears first.. e.g: EVP_MD_fetch(digestname, libctx, propq); This now logically reads as 'search for this algorithm using these parameters’. The libctx, propq should always appear

Re: Reordering new API's that have a libctx, propq

Thanks for the writeup.. > My view is that the importance of arguments is what sets their order - and > that is why for the TYPE functions the TYPE pointer > comes first. We could have just as easily specified it as last or some other > order, but we didn’t. Isn’t that the order that the fetch

Re: Reordering new API's that have a libctx, propq

The example given was EVP_PKEY_get_() and from the API name it is fairly clear what the first param should be EVP_PKEY *pkey (the API tells you this). For the fetch case, I still think that the algorithm is the most important param. Libctx, propq are optional parameters as far as I am

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

-1 > On 9 Oct 2020, at 7:40 am, Dr Paul Dale wrote: > > +1 > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 9 Oct 2020, at 12:27 am, Matt Caswell > > wrote: >> >> topic:

Re: Vote proposal: Private keys can exist independently of public keys

I assume you are just talking about the ec key? If the public key is not present then that could be seen as an error for operations that require the public key. Shane > On 7 Oct 2020, at 9:54 pm, Dr Paul Dale wrote: > > Would it be feasible to change code that does ->pub_key to call a

Re: Freeze?

I think this best describes the issue: https://www.youtube.com/watch?v=zsKOYQ7z9CE > On 26 Sep 2020, at 9:17 am, Benjamin Kaduk wrote: > > On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote: >> I’m seeing quite a bit of activity going on

Re: RAND_DRBG

i.e. Choose option (1) > On 27 Jul 2020, at 11:14 am, SHANE LONTIS wrote: > > If this is not going to break 99% of users + it improves the interface + the > replacement to achieve the same is a few lines of code and is likely to occur > in one place in an app, then it s

Re: RAND_DRBG

If this is not going to break 99% of users + it improves the interface + the replacement to achieve the same is a few lines of code and is likely to occur in one place in an app, then it seems reasonable to change it to me. > On 27 Jul 2020, at 11:08 am, Dr Paul Dale wrote: > > The RAND_DRBG

Re: API renaming

For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’ is not a particularly great rule either. We should decide which one to use and stick to it. > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > A couple of points: > > 1. Quite a while ago, we (the team at the time) made a decision to >

Re: API renaming

development is still not frozen (alpha), so I for one could > easily see a rename fest happening, should we decide for it. That > must happen before we enter the beta phase, though... > > On Fri, 24 Jul 2020 07:55:10 +0200, > SHANE LONTIS wrote: >> >> For (1) the us

Re: API renaming

As @levitte pointed out - it was not back ported (not sure why I thought it was) > On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre > wrote: > > > I think the KDF and MAC got back ported also... > > In this case it would be no question that we should keep the names EVP_KDF > and

Re: API renaming

I was thinking OSSL_LIBCTX? > On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre > wrote: > > I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with > Shane > that we should go for a single prefix and not have two alternatives. Existing > prefixes > for things like

Re: OTC VOTE: Keeping API compatibility with missing public key

+1 > On 4 Dec 2020, at 10:45 pm, Tomas Mraz wrote: > > Vote background > --- > > The vote on relaxing the conceptual model in regards to required public > component for EVP_PKEY has passed with the following text: > > For 3.0 EVP_PKEY keys, the OTC accepts the following

Re: OTC VOTE: Fixing missing failure exit status is a bug fix

+1 > On 30 Nov 2020, at 10:03 pm, Nicola Tuveri wrote: > > Vote background > --- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with

Re: OTC VOTE: EVP_PKEY private/public key components

Key assurance really depends on what you are doing, so I don't think this is quite true. For example if you generate a key using a valid algorithm (that is validated by a lab), then there is already an assurance that the key is valid without needing to run EVP_PKEY_check(). There are many

Re: [External] : OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely

0 > On 23 Feb 2021, at 8:21 pm, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless

Re: [External] : Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

Nicola we already have a interface that sets blinding to on or off.. > On 9 Apr 2021, at 9:48 am, Nicola Tuveri wrote: > > Thanks for the feedback Tim! > I see your points and I value the discussion. > > Reading your message I realized that probably I got carried away in some of > the

Re: [External] : OTC VOTE: Reject PR#14759

+1 Shane > On 20 Apr 2021, at 8:23 pm, Nicola Tuveri wrote: > > Following up on > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html >

Re: [External] : Agenda for the next OTC meeting

I would like to also discuss code coverage, and in particular adding tests for any new code that is added. From: openssl-project on behalf of Matt Caswell Sent: Tuesday, October 12, 2021 10:23 PM To: openssl-project@openssl.org Subject: [External] : Agenda for

Re: [External] : OTC VOTE: Accept Policy change process proposal

+1 From: openssl-project on behalf of Tomas Mraz Sent: Monday, November 1, 2021 8:23 PM To: openssl-project@openssl.org Subject: [External] : OTC VOTE: Accept Policy change process proposal topic: Accept openssl/technical-policies PR#1 - the policy change

Re: [External] : OTC VOTE: Accept PR 16128

+1 From: openssl-project on behalf of Matt Caswell Sent: Thursday, July 22, 2021 10:51 PM To: openssl-project@openssl.org Subject: [External] : OTC VOTE: Accept PR 16128 topic: Accept PR 16128 in 3.0 subject to our normal review process Proposed by Matt

Re: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

Vote [+1] I view this as a bug fix. From: openssl-project on behalf of Nicola Tuveri Sent: Wednesday, November 16, 2022 1:00 AM To: OpenSSL Project Subject: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process Topic: Accept PR