Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
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

2019-06-04 Thread SHANE LONTIS
> On 5 Jun 2019, at 12:34 pm, Richard Levitte wrote: > > Aside from the discussion below, if there's one thing I would like to > change, it the double indirection for the _PTR data types. The data > types could still be used to indicate that the value isn't short > lived, but could possibly

Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
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

2019-05-24 Thread SHANE LONTIS
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..

2020-03-03 Thread SHANE LONTIS
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?

2020-02-09 Thread SHANE LONTIS
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

2020-02-21 Thread SHANE LONTIS
> 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

2020-03-30 Thread SHANE LONTIS
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

2020-05-01 Thread SHANE LONTIS
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

2020-09-04 Thread SHANE LONTIS
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

2020-09-05 Thread SHANE LONTIS
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

2020-09-06 Thread SHANE LONTIS
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: Technical Items still to be done

2020-10-08 Thread SHANE LONTIS
+1 > On 9 Oct 2020, at 12:47 am, 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

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

2020-10-08 Thread SHANE LONTIS
-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: Weekly OTC meetings until 3.0 beta1 is released

2020-10-09 Thread SHANE LONTIS
[+1] (reluctantly committing to 3 hour meetings :)) > On 9 Oct 2020, at 10:00 pm, 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

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

2020-10-10 Thread SHANE LONTIS
0 > On 9 Oct 2020, at 10:02 pm, 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

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

2020-10-07 Thread SHANE LONTIS
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?

2020-09-25 Thread SHANE LONTIS
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

2020-07-26 Thread SHANE LONTIS
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

2020-07-26 Thread SHANE LONTIS
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

2020-07-23 Thread SHANE LONTIS
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

2020-07-24 Thread SHANE LONTIS
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

2020-07-24 Thread SHANE LONTIS
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

2020-07-24 Thread SHANE LONTIS
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

2020-12-04 Thread SHANE LONTIS
+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

2020-11-30 Thread SHANE LONTIS
+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

2020-11-11 Thread SHANE LONTIS
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

2021-02-23 Thread SHANE LONTIS
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