summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/crypto_ex_data.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bump CRYPTO_EX_DATA_MAX_INDEX to 32tb2024-08-031-2/+2
| | | | | | | | | rust-openssl tests do something weird and need lots of ex data (one index for each registered callback, for example). This makes the regress pass again. noticed by anton ok jsing
* Use proper size for allocating indexestb2024-08-031-2/+2
| | | | | | | | | It's a double pointer, so we should allocate a pointer size, not the entire struct. This saves roughly 500B per class. CID 507397 ok jsing
* free class->indexes in CRYPTO_cleanup_all_ex_data()tb2024-08-021-1/+2
| | | | ok jsing
* Rewrite CRYPTO_EX_DATA.jsing2024-08-021-0/+417
CRYPTO_EX_DATA exists as a way to allow an application to attach data to various components in libcrypto and libssl. The general idea is that there are various "classes" (e.g. RSA) and an application can get an "index" (which can have new/dup/free functions provided). The application can then use the index to store a pointer to some form of data within that class, for later retrieval. However, even by OpenSSL standards, this is an insane API. The current implementation allows for data to be set without calling new, indexes can be used without allocation, new can be called without actually getting an index and dup can be called either after new or without new (see regress and RSA_get_ex_new_index(3)/CRYPTO_set_ex_data(3) for more details). On top of this, the previous "overhaul" of the code was written to be infinitely extensible. For now, the rewrite intends to maintain the existing behaviour - once we bed this down we can attempt to ratchet the API requirements and require some sort of sensible sequence. The only intentional change is that there is now a hard limit on the number of indexes that can be allocated (previously there was none, relying only on ENOMEM). ok tb@