On Mon, 18 Feb 2019 11:17:45 +0100,
Matt Caswell wrote:
> At the moment OPENSSL_CTX is implemented using CRYPTO_EX_DATA. An alternative
> implementation approach would be that the struct is internally transparent and
> is just a bucket of stuff (without using CRYPTO_EX at all). I guess the reason
>
On Mon, Feb 18, 2019 at 8:36 PM Matt Caswell wrote:
>
>
> On 18/02/2019 10:28, Tim Hudson wrote:
> > It should remain completely opaque.
> > As a general rule, I've never seen a context where someone regretted
> making a
> > structure opaque over time, but the converse is not true.
> > This is op
On 18/02/2019 10:28, Tim Hudson wrote:
> It should remain completely opaque.
> As a general rule, I've never seen a context where someone regretted making a
> structure opaque over time, but the converse is not true.
> This is opaque and should remain opaque.
> We need the flexibility to adjust
It should remain completely opaque.
As a general rule, I've never seen a context where someone regretted making
a structure opaque over time, but the converse is not true.
This is opaque and should remain opaque.
We need the flexibility to adjust the implementation at will over time.
For anything
On 18/02/2019 01:38, Michael Richardson wrote:
>
> Paul Dale wrote:
> > Library contexts are going to allow us to separate different portions
> of the
> > TLS/cryptographic activity within one application. No problems, here.
> This
> > seems like a useful and worthwhile idea. It
Paul Dale wrote:
> Library contexts are going to allow us to separate different portions of
the
> TLS/cryptographic activity within one application. No problems, here. This
> seems like a useful and worthwhile idea. It will e.g. be a way to separate
> FIPS and non-FIPS streams ni
On Sun, 17 Feb 2019 23:18:08 +0100,
Paul Dale wrote:
> Library contexts are going to allow us to separate different portions of the
> TLS/cryptographic
> activity within one application. No problems, here. This seems like a
> useful and worthwhile
> idea. It will e.g. be a way to separate FIPS
Library contexts are going to allow us to separate different portions of the
TLS/cryptographic activity within one application. No problems, here. This
seems like a useful and worthwhile idea. It will e.g. be a way to separate
FIPS and non-FIPS streams nicely.
I've a reservation about the