Just wondering (having not thought this properly through): would it be reasonable to register the "openssl_ctx_run_once" calls like the "openssl_ctx_onfree" ones and make them automatic?

Just wondering (having not thought this properly through): would it be reasonable to register the "openssl_ctx_run_once" calls like the "openssl_ctx_onfree" ones and make them automatic?

Where would you register them? As a hard coded list perhaps? There are pros and cons:

pro: you don't have to check all the time whether you've done the initialisation yet
con: initialisation is no longer "on demand" so you might end up allocating lots of resources that you don't end up using

fixup up pushed to address "make update" issues.

Another fixup to address a mem leak.

con: initialisation is no longer "on demand" so you might end up allocating lots of resources that you don't end up using

Even if registered before time (a fixed list is a good place), they'd only be called on context creation. Does that necesarily imply a cascade of other initialisers being called independent of what gets used by the applications??

Question: did you have to put ex_data class data in the global context for some reason, or did you just take "everything" in #8760 more literally than I meant it?

My thoughts, that I may or may not have shared, is that the ex_data class data would remain global (note: global to the module that includes the ex_data object file)

Not sure whether to replace that PR with this one or keep it separate.

I think this should be an entirely separate PR. There's nothing in this PR that should be inherently dependant on #8728, and having the two mixed in one PR makes it harder to review this one.

Question: did you have to put ex_data class data in the global context for some reason, or did you just take "everything" in #8760 more literally than I meant it?

Yes. This solves the problem of the ex_data_lock. By tying it to the lifetime of the OPENSSL_CTX we avoid all the issues we were having with freeing it on the provider side. I see no reason to treat that global data differently to any other global data. In fact its kind of weird not to. This makes things conceptually much simpler.

This makes things conceptually much simpler.

I disagree, especially on a conceptual level. See it like this, the OSSL_EX_DATA_GLOBAL is class data (not class instance data), and with the changes made here, you have basically made it so that you define the class data in terms of instances of that class. Conceptually speaking, that's not simple, not one bit.

I disagree, especially on a conceptual level. See it like this, the OSSL_EX_DATA_GLOBAL is class data (not class instance data), and with the changes made here, you have basically made it so that you define the class data in terms of instances of that class. Conceptually speaking, that's not simple, not one bit.

I think you are overcomplicating it. Think of OPENSSL_CTX as a scope. The OSSL_EX_DATA_GLOBAL is class data for all classes within that scope. The OPENSSL_CTX class of objects is slightly different to other classes in that there is only ever one instance within a given scope. I don't think this is a problem.

I updated this to remove the dependency on #8728.

I updated this to remove the dependency on #8728.

Thank you!

The reason you're getting build errors on Windows is the new inclusion of "internal/cryptlib.h" in include/internal/property.h, which is included by test/property_test.c. The simple solution is this:

: ; git diff
diff --git a/test/build.info b/test/build.info
index ded3bd770a..2800c71d3e 100644
--- a/test/build.info
+++ b/test/build.info
@@ -503,7 +503,7 @@ IF[{- !$disabled{tests} -}]
     DEPEND[wpackettest]=../libcrypto ../libssl.a libtestutil.a
 
     SOURCE[property_test]=property_test.c
-    INCLUDE[property_test]=../include ../apps/include
+    INCLUDE[property_test]=.. ../include ../apps/include
     DEPEND[property_test]=../libcrypto.a libtestutil.a
 
     SOURCE[ctype_internal_test]=ctype_internal_test.c

These manuals need an update:

• doc/internal/man3/ossl_method_construct.pod
• doc/internal/man3/OSSL_METHOD_STORE.pod
• doc/internal/man3/openssl_ctx_get_data.pod

Just wondering (having not thought this properly through): would it be reasonable to register the "openssl_ctx_run_once" calls like the "openssl_ctx_onfree" ones and make them automatic?

After a bit of "Doh!" moment I realised that we could do this with all of the openssl_ctx_init_index calls - and suddenly you don't need some of the run_once calls at all because a number of them were only there to initialise the index. Furthermore, I realised I wasn't using OPENSSL_CTX quite right and I could move even more initialisation code into the OPENSSL_CTX_METHOD "new" functions. This significantly simplifies things. Most code can just set up an OPENSSL_CTX_METHOD and it all just initialises itself when needed and frees itself when the OPENSSL_CTX_METHOD is freed. No need to call openssl_ctx_run_once or openssl_ctx_onfree at all.

There is still one spot where openssl_ctx_run_once is required. There are no places where openssl_ctx_onfree is now needed, although I have left the implementation there since I suspect it will be needed as we roll this out to more places in the code.

New commits pushed addressing the feedback and making the changes described above. Taking this out of WIP.

The simple solution is this

Thanks for the hint. Should be sorted now. Also I updated the internal manuals as requested.

Updated to address @levitte's feedback.

So, what about #8857 (comment)?

(other than that, I'm not reasonably happy with this PR)

So, what about #8857 (comment)?

Responded to

Pusehd! Thanks.

(other than that, I'm not reasonably happy with this PR)

I suppose you meant now instead of not :)

(other than that, I'm not reasonably happy with this PR)

I suppose you meant now instead of not :)

Uhmmmm... yes!