Reordering new API's that have a libctx, propq

[Dr Paul Dale]

Still no need for the added complexity:

Push:
	OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);

Pop is:
	OPENSSL_CTX_set0_default(prevctx);

Push before callback:
	OPENSSL_CTX_set0_default(prevctx);

Pop after callback:
	prevctx = OPENSSL_CTX_set0_default(libctx);
or
	OPENSSL_CTX_set0_default(libctx);
Depending if we want to support call backs changing the Libctx directly — we should choose one and always recommend that.


Also the auto allocation of storage for the second on stack cannot fail, so no error checking spaghetti.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 10 Sep 2020, at 12:08 am, Tomas Mraz <tmraz at redhat.com> wrote:
> 
> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
>>> On 9 Sep 2020, at 9:38 pm, Tomas Mraz <tmraz at redhat.com> wrote:
>>> 
>>> We could even provide a convenience thread local stack of lib
>>> contexts
>>> so the caller would not have to keep the old value but would just
>>> push
>>> the new libctx when entering and pop the old one when leaving. With
>>> that, I think the changes needed in the application code would be
>>> fairly simple and minimal.
>> 
>> Let’s not overcomplicate things.
>> We went through this discussion back when this was introduced.
>> 
>> 
>> Push is:
>>    OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
>> 
>> Pop is:
>>    OPENSSL_CTX_set0_default(prevctx)
>> 
>> 
>> I don’t see having an explicit stack of these is of any benefit to
>> anything but unwarranted complexity.
> 
> There is one thing where it would be IMO helpful - let's say libcurl
> has a callback into a calling application. With the current API in
> libcurl API calls you would put the
> calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
> ) at the beginning and end. But you would have to save the prevctx
> somewhere in the libcurl context structure because on callbacks you
> would have to temoprarily reset the context to the prevctx value. If we
> implemented real stack it would not be needed. But yeah, I am not sure
> this convenience is that much worth it.
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>                                              Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200910/9a7cb9d5/attachment-0001.html>