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
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
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
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
