[Pending on #10390] CORE & PROV: make export of key data leaner through callback#10391
[Pending on #10390] CORE & PROV: make export of key data leaner through callback#10391levitte wants to merge 1 commit intoopenssl:masterfrom
Conversation
Exporting data from a provider owned domainparams or key is quite an ordeal, with having to figure out what parameter keys an implementation supports, call the export function a first time to find out how large each parameter buffer must be, allocate the necessary space for it, and call the export function again. So how about letting the export function build up the key data params and call back with that? This change implements exactly such a mechanism.
levitte
changed the title
|
Builds will very obviously fail as long as #10390 hasn't been merged and this PR hasn't been rebased on top of that |
|
I dont know if this is a good idea. |
|
I did use an internal parameter builder, but not the kind of thing you are thinking of. It involved getting to know what data can be requested (a gettable call), building a template OSSL_PARAM array with all of them, calling the provider side data exporting function to find out what size they should be (i.e. getting return_size filled in), allocating storage for all the data, and finally call the exporting function once more to get the actual data. All of that got replaced with a call to the exporting function and tell it to send the resulting OSSL_PARAM array to "that callback over there". The provider gets to use the param builder I think you're thinking of to create its OSSL_PARAM array once, directly from known data, and simply pass it back. Ownership of that OSSL_PARAM array stays with the provider. The change is much simpler and requires much less churn. |
|
Do note that this also allows for much easier chaining of things to do. I take full advantage of that in #10394 |
|
Closing this in favor of #10414 |
2 participants
Exporting data from a provider owned domainparams or key is quite an
ordeal, with having to figure out what parameter keys an
implementation supports, call the export function a first time to find
out how large each parameter buffer must be, allocate the necessary
space for it, and call the export function again.
So how about letting the export function build up the key data params
and call back with that? This change implements exactly such a
mechanism.