This adds 2 things to the ENGINE code.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself that allows an ENGINE to store its own information there rather than in global variables. It follows the declarations and implementations used in RSA code, for better or worse. However there's a problem when storing state with ENGINEs because, unlike related structure types in OpenSSL, there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE is, it has method pointers as its structure elements ... which leads to; * ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a reference to an "implementation" (eg. to get to a hardware device), but should also be able to maintain state, then this flag can be set by the ENGINE implementation. The result is that any call to ENGINE_by_id() will not result in the existing ENGINE being returned (with its structural reference count incremented) but instead a new copy of the ENGINE will be returned that can maintain its own state independantly of any other copies returned in the past or future. Eg. key-generation might involve a series of ENGINE-specific control commands to set algorithms, sizes, module-keys, ids, ACLs, etc. A final command could generate the key. An ENGINE doing this would *have* to declare ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be maintained "per-handle" and unaffected by other code having a reference to the same ENGINE structure.
parent
21023745
Please register or sign in to comment