On Wed, 05 Jun 2019 03:17:25 +0200,
Salz, Rich wrote:
>
>
> * Is this workable or should something more significantly different be used
> before things freeze
> with the 3.0 release?
>
> Well, since you asked: https://github.com/openssl/openssl/pull/8377
For the record, I'm opposed to
* Is this workable or should something more significantly different be used
before things freeze with the 3.0 release?
Well, since you asked: https://github.com/openssl/openssl/pull/8377
On Wed, 05 Jun 2019 05:07:24 +0200,
Dr Paul Dale wrote:
>
>
> Richard wrote:
>
> With most OSSL_PARAM structure being dynamically created,
> the need for the indirection seems redundant. E.g. could the return
> length be moved into
> OSSL_PARAM? I think so.
>
>
The OSSL_PARAM structure needs to be visible and not subject to change.
Providers shouldn’t necessarily have a dependency on functions from libcrypto.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 5 Jun 2019, at 12:47 pm,
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 5 Jun 2019, at 12:47 pm, Richard Levitte wrote:
> But you're talking about allocating the whole OSSL_PARAM array on the
> heap, aren't you? While not structly opposed (even though
Richard wrote:
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> So while this is an issue for *us*, it isn't necessarily an issue for
> our users, all depending on what C language version they use.
Supporting things *we* can’t use seems
On Wed, 05 Jun 2019 03:11:57 +0200,
Dr Paul Dale wrote:
>
>
> For a minimally invasive change, the various OSSL_PARAM_construct_ calls
> could be modified to
> allocate space for the parameter and its return size if NULL is passed for
> either.
If NULL is passed as return_size, it means the
I assume you're talking about the |return_size| indirection here.
I think you will see much more of them as soon as the asymmetric
algorithms start to show up, as they should naturally contain
get_params functionality for the numbers of the key objects. For the
moment being, we aren't seeing much
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 change names to something like
OSSL_PARAM_UTF8_CSTRING and
For a minimally invasive change, the various OSSL_PARAM_construct_ calls could
be modified to allocate space for the parameter and its return size if NULL is
passed for either.
There would need to be some indication of this and a cleanup array call.
Done properly, this would permit the same
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
On Tue, 04 Jun 2019 14:57:00 +0200,
Salz, Rich wrote:
>
>
> >Part of the idea was that this would be a means of communication
> between application and provider, just like controls are with
> libcrypto sub-systems.
>
>
> I can probably find the email thread (or maybe it was a
>Part of the idea was that this would be a means of communication
between application and provider, just like controls are with
libcrypto sub-systems.
I can probably find the email thread (or maybe it was a GitHub comment on my
proposal for params), where you said, quite
Part of the idea was that this would be a means of communication
between application and provider, just like controls are with
libcrypto sub-systems.
The main differences are that we aren't stuck with the limitations of
the control functions, that the interface is uniform (if you look at
the
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
15 matches
Mail list logo
