I presume the reference approach was used to solve the issue of who actually owns/free's the data.
> On 5 Jun 2019, at 9:18 am, Dr Paul Dale <paul.d...@oracle.com> wrote: > > Shane’s major complaints are about the indirection the OSSL_PARAM structure > forces — for integers and return lengths and the necessity of allocating > additional memory in parallel with the OSSL_PARAM. > > The extra indirection was intended to support const arrays of OSSL_PARAM, > which turn out to be a rarity because they aren’t thread safe. With most > OSSL_PARAM structure being dynamically created, the need for the indirection > seems redundant. E.g. could the return length be moved into OSSL_PARAM? I > think so. > > Moving integral values into the structure is more difficult because BIGNUMs > will always need to be references. Allocating additional memory will still > be required. I’ve got three obvious solutions: > > 1. include a void * in the OSSL_PARAM structure that needs to be freed when > the structure is destroyed or > 2. have a block of data in the OSSL_PARAM structure that can be used for > native types (OSSL_UNION_ALIGN works perfectly for this) or > 3. add a flag field to the OSSL_PARAM to indicate that the referenced value > needs to be freed. > > The memory allocation comes to the for when reading e.g. a file and > extracting data — either the reader needs a lot of local variables to hold > everything or it has to allocated for each. The file’s data is transient in > memory. > > > For the most part, the receiver side APIs seem reasonable. It is the owning > side that has the complications. > > I think I might be able come up with some owner side routines that assist > here but allowing changes to the params structure would be far easier. > > > I kind of like using the OSSL_PARAM arrays as a replacement for string ctrl > functions if not ctrl as well (subject to backward compatibility concerns). > > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > >> On 4 Jun 2019, at 11:26 pm, Richard Levitte <levi...@openssl.org >> <mailto:levi...@openssl.org>> wrote: >> >> On Tue, 04 Jun 2019 14:57:00 +0200, >> Salz, Rich wrote: >>> >>> >>>> Part of the idea was that this would be a means of communication >>> between application and provider, just like controls are with >>> libcrypto sub-systems. >>> >>> >>> I can probably find the email thread (or maybe it was a GitHub >>> comment on my proposal for params), where you said, quite >>> definitively, that this was *not* a general-purpose mechanism but >>> rather a way to expose the necessary internals for opaque objects >>> like RSA keys. >> >> Either I misunderstood what you said at the time, or you misunderstood >> what I said... there's definitely a disconnect here somewhere. >> >> What I wonder is why it should be exclusively only one of those >> options? >> >> Either way, the OSSL_PARAM is defined publically and openly (i.e. >> non-opaque), and we currently have the following functions in the >> public API: >> >> EVP_MD_CTX_set_params >> EVP_MD_CTX_get_params >> OSSL_PROVIDER_get_params >> >> I fully expect that more will come. I have a branch where I've >> EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if >> EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before >> long (I'm actually rather surprised they haven't already), and I'm >> absolutely sure we will see similar functions for asymmetric >> algorithms. >> >>> What changed your mind? >>> >>> Perhaps not surprisingly, I agree with Shane's assessment and am >>> strongly opposed to the project foisting this on everyone at this >>> time. @DavidBen, your thoughts? >> >> Maybe we're reading differently, I didn't see Shane being opposed to >> parameter passing in this way per se, just the exact form of the >> OSSL_PARAM structure, which is different. >> >> Cheers, >> Richard >> >> -- >> Richard Levitte levi...@openssl.org <mailto:levi...@openssl.org> >> OpenSSL Project http://www.openssl.org/~levitte/ >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org_-7Elevitte_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk&m=ngbUohXK9OQMcC6T1S9Xvhy8OvC7dSslJ9RwAfHWnek&s=pbKG4wSDo_zd6yyp8bCPGDKXxFbG0-M5B4SRDEB-XA4&e=>
