Serialisation: add a built-in serialisation provider. #12104
Conversation
|
This separates out the serialisation into a separate provider, however it lives in libcrypto and is included in the default provider automatically. The FIPS provider needs to load this when it is loaded and unload it when it is unloaded. Added a |
providers/build.info
Outdated
Show resolved
Hide resolved
apps/list.c
Outdated
Show resolved
Hide resolved
|
Note: there appears to be a lock order inversion that is trigger by this change. |
|
The threading issue is reported in #12151 (which is on master). |
|
Out of WIP. The threading issue that caused the lock up was a result of a problem with this PR (i.e. the issue existed regardless but was triggered due to a problem here). The "provider=" properties for the serialisers is fixed as serialization even if it comes from the default provider. I don't see this as being a problem, but if others disagree, it can be fixed easily. |
That has me wonder what the meaning is with that particular property. Why have it at all? |
|
We've got "provider=XXX" for all other instances. In this case the provider is the serialization provider even if it isn't loaded. As I mentioned, I'm happy to change this to provider=default. Regardless, provider=serialization will always be exactly equivalent to provider=default. Examine the output of |
doc/man7/OSSL_PROVIDER-default.pod
Outdated
Show resolved
Hide resolved
|
I noticed, with some amusement, the spelling change from "serialise" to "serialize"... I actually thought the 's' spelling was favoured in AU For further amusement: https://english.stackexchange.com/questions/38232/usage-of-z-in-the-word-serialized-in-english |
|
English uses 'z' and 's' in -[sz]se pretty much interchangeably, alhtough 's' is generally preferred. American only uses 'z'. My preference is towards 's'. However, there were plenty of instances using 'z' already in the code, which made standardising on that reasonable. Yes, I used 's' deliberately :) |
|
Ping @openssl/committers |
Reminds me of how yesterday I got a build error in my new code by putting in a check against |
I'm happy to duplicate the table, I don't really see a need for this property. People want an implementation that conforms to X, the provider should be irrelevant. It was introduced so that the default and FIPS providers could coexist and share the serialisation. I'd vote to remove it -- albeit not as part of this PR. |
In English, either I went through the code and noticed that there were far more That written, I'll happily change all to the |
Yes, but if we do specify it, it should be correct. |
Most of us at least |
|
Review comments addressed. Apart from unifying the spelling of all the -ise and -ize words. I'm happy to drop the changes I did in this area so that something with wider coverage can be done in the future. |
|
Ping for review. |
|
All bar listing the FIPS serialisers fixed. |
|
doc-nits failure reported by travis sees relevant. The test_verify failure OTOH looks odd. Several failures due to that but I can't see how it is related. |
|
Looks good except for the travis issues. |
This is fixed by #12549 |
|
Had to miss something. Should be fixed now. |
Move the libcrypto serialisation functionality into a place where it can be provided at some point. The serialisation still remains native in the default provider. Add additional code to the list command to display what kind of serialisation each entry is capable of. Having the FIPS provider auto load the base provider is a future (but necessary) enhancement.
|
I've squashed an rebased the changes -- the build failure was a link fix in the documentation. I've also added a fixup commit that adds a |
|
I'm slightly confused by the Travis status showing in this PR. It's showing as queued. However here it is showing as green: So - approved on that basis. |
|
Travis showed up twice when I last pushed. Both builds have the same ID (36399). I've no idea why this happened. |
https://travis-ci.community/t/build-config-running-twice/6985 |
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #12104)
Move the libcrypto serialisation functionality into a place where it can be provided at some point. The serialisation still remains native in the default provider. Add additional code to the list command to display what kind of serialisation each entry is capable of. Having the FIPS provider auto load the base provider is a future (but necessary) enhancement. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #12104)
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #12104)
|
Merged to master. Thanks for all the reviews etc. |
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from openssl#12104)
Move the libcrypto serialisation functionality into a place where it can be provided at some point. The serialisation still remains native in the default provider. Add additional code to the list command to display what kind of serialisation each entry is capable of. Having the FIPS provider auto load the base provider is a future (but necessary) enhancement. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from openssl#12104)
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from openssl#12104)
Move the libcrypto serialisation functionality into a place where it can be provided at some point. The serialisation still remains native in the default provider.
Add additional code to the list command to display what kind of serialisation each entry is capable of.
Having the FIPS provider auto load the serialisation provider is a future (but necessary) enhancement.