<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I thought the references were to allow const arrays of OSSL_PARAM to be viable.<div class=""><br class=""><div class="">A quick check through the code reveals these in test and doc only.  There are two instances of OSSL_PARAM arrays being declared in evp, both add the pointed to variable after creation, both only have two elements (the integer and the terminator) and both are stack allocated.  I.e. there is currently is no example of the use case for which the indirection is present :(</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pauli<br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">-- <br class="">Dr Paul Dale | Cryptographer | Network Security & Encryption <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 5 Jun 2019, at 10:31 am, SHANE LONTIS <<a href="mailto:shane.lontis@oracle.com" class="">shane.lontis@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I presume the reference approach was used to solve the issue of who actually owns/free's the data.</div><div class=""> <div class=""><div class="">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div></div><div class=""><blockquote type="cite" class=""><div class="">On 5 Jun 2019, at 9:18 am, Dr Paul Dale <<a href="mailto:paul.dale@oracle.com" class="">paul.dale@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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:</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">1. include a void * in the OSSL_PARAM structure that needs to be freed when the structure is destroyed or</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">3. add a flag field to the OSSL_PARAM to indicate that the referenced value needs to be freed.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For the most part, the receiver side APIs seem reasonable.  It is the owning side that has the complications.</div><div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pauli<br class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">-- <br class="">Dr Paul Dale | Cryptographer | Network Security & Encryption <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><br class="Apple-interchange-newline"></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 4 Jun 2019, at 11:26 pm, Richard Levitte <<a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, 04 Jun 2019 14:57:00 +0200,<br class="">Salz, Rich wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">  Part of the idea was that this would be a means of communication<br class=""></blockquote>   between application and provider, just like controls are with<br class="">   libcrypto sub-systems.<br class=""><br class=""><br class="">I can probably find the email thread (or maybe it was a GitHub<br class="">comment on my proposal for params), where you said, quite<br class="">definitively, that this was *not* a general-purpose mechanism but<br class="">rather a way to expose the necessary internals for opaque objects<br class="">like RSA keys.<br class=""></blockquote><br class="">Either I misunderstood what you said at the time, or you misunderstood<br class="">what I said...  there's definitely a disconnect here somewhere.<br class=""><br class="">What I wonder is why it should be exclusively only one of those<br class="">options?<br class=""><br class="">Either way, the OSSL_PARAM is defined publically and openly (i.e.<br class="">non-opaque), and we currently have the following functions in the<br class="">public API:<br class=""><br class="">   EVP_MD_CTX_set_params<br class="">   EVP_MD_CTX_get_params<br class="">   OSSL_PROVIDER_get_params<br class=""><br class="">I fully expect that more will come.  I have a branch where I've<br class="">EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if<br class="">EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before<br class="">long (I'm actually rather surprised they haven't already), and I'm<br class="">absolutely sure we will see similar functions for asymmetric<br class="">algorithms.<br class=""><br class=""><blockquote type="cite" class="">What changed your mind?<br class=""><br class="">Perhaps not surprisingly, I agree with Shane's assessment and am<br class="">strongly opposed to the project foisting this on everyone at this<br class="">time.  @DavidBen, your thoughts?<br class=""></blockquote><br class="">Maybe we're reading differently, I didn't see Shane being opposed to<br class="">parameter passing in this way per se, just the exact form of the<br class="">OSSL_PARAM structure, which is different.<br class=""><br class="">Cheers,<br class="">Richard<br class=""><br class="">--<span class="Apple-converted-space"> </span><br class="">Richard Levitte         <a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a><br class="">OpenSSL Project         <a href="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=" class="">http://www.openssl.org/~levitte/</a></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></body></html>