CRYPTO_GET_EX_NEW_INDEX(3ossl)

📦
version 15.1 · 2 versions
, in freebsd 15.1

💖 NAME 💖

okay so bestie, this page covers the whole exdata squad — CRYPTO_EX_new, CRYPTO_EX_free, CRYPTO_EX_dup, CRYPTO_free_ex_index, CRYPTO_get_ex_new_index, CRYPTO_alloc_ex_data, CRYPTO_set_ex_data, CRYPTO_get_ex_data, CRYPTO_free_ex_data, and CRYPTO_new_ex_data — literally all the functions that support application-specific data. this is from the 3ossl manual, bestie, and it's giving "attach your own stuff to OpenSSL structs" energy 💅

✨ SYNOPSIS ✨

#include <openssl/crypto.h>

int CRYPTO_get_ex_new_index(int class_index,
                            long argl, void *argp,
                            CRYPTO_EX_new *new_func,
                            CRYPTO_EX_dup *dup_func,
                            CRYPTO_EX_free *free_func);

typedef void CRYPTO_EX_new(void *parent, void *ptr, CRYPTO_EX_DATA *ad,
                           int idx, long argl, void *argp);
typedef void CRYPTO_EX_free(void *parent, void *ptr, CRYPTO_EX_DATA *ad,
                            int idx, long argl, void *argp);
typedef int CRYPTO_EX_dup(CRYPTO_EX_DATA *to, const CRYPTO_EX_DATA *from,
                          void **from_d, int idx, long argl, void *argp);

int CRYPTO_new_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad);

int CRYPTO_alloc_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad,
                         int idx);

int CRYPTO_set_ex_data(CRYPTO_EX_DATA *r, int idx, void *arg);

void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *r, int idx);

void CRYPTO_free_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *r);

int CRYPTO_free_ex_index(int class_index, int idx);

🦋 DESCRIPTION 🦋

soooo a bunch of OpenSSL structures can have your own app-specific data glued onto them, and the girlies call it "exdata" 🎀 the structures in question are literally:

BIO
DH
DSA
EC_KEY
ENGINE
EVP_PKEY
RSA
SSL
SSL_CTX
SSL_SESSION
UI
UI_METHOD
X509
X509_STORE
X509_STORE_CTX

plus the name APP is reserved for your application code to use, so like, that one's yours 👑

each of these is identified by a CRYPTO_EX_INDEX_xxx define in <openssl/crypto.h>. and bonus: CRYPTO_EX_INDEX_APP is reserved so applications can use this whole facility on their own structures. main character energy fr 💜

the API here is what OpenSSL itself uses to manipulate exdata on specific structures. and because your application data can literally be anything at all, it gets passed around and retrieved as a void * type — no cap.

the CRYPTO_EX_DATA type is opaque (mysterious, we love that 🙈). to initialize the exdata part of a structure, call CRYPTO_new_ex_data(). this is only necessary for CRYPTO_EX_INDEX_APP objects, okay?

exdata types are identified by an index — an integer that's guaranteed to be unique within structures for the entire lifetime of the program. apps using exdata typically call CRYPTO_get_ex_new_index at startup and store the result in a global variable, or write a wrapper function to provide lazy evaluation (slay). the class_index should be one of the CRYPTO_EX_INDEX_xxx values. the argl and argp parameters get saved so they can be passed to the callbacks, but otherwise they're not used at all. and to transparently manipulate exdata you gotta provide three callbacks — their semantics are described below, keep scrolling bestie 💅

when copying or releasing objects with exdata, the callback functions are called in increasing order of their index value 🔥

important bestie: if a dynamic library can be unloaded, it should call CRYPTO_free_ex_index() when that happens. this replaces the callbacks with no-ops so applications don't crash 💀 but heads up — any existing exdata will be leaked. yeah. that part.

to set or get the exdata on an object, you must use the appropriate type-specific routine. why? because the containing structure is opaque and the CRYPTO_EX_DATA field is not accessible 🙃 in both APIs, the idx parameter should be an already-created index value.

when setting exdata, the pointer you specify with a particular index gets saved and returned on a subsequent "get" call. if the application is going to release the data, it must make sure to set a NULL value at the index — otherwise, likely double-free crashes 😭 not cute, don't do it.

the function CRYPTO_free_ex_data is used to free all exdata attached to a structure. the appropriate type-specific routine must be used. the class_index identifies the structure type, obj is a pointer to the actual structure, and r is a pointer to the structure's exdata field. periodt.

🌸 Callback Functions 🌸

this section describes how the callback functions are used. applications defining their own exdata using CYPRTO_EX_INDEX_APP must call them as described here. (yes that's how it's spelled in the original, i don't make the rules 🫶)

when a structure is initially allocated (such as RSA_new()) then the new_func() is called for every defined index. there's no requirement that the entire parent — or containing — structure has been set up. the new_func() is typically used only to allocate memory to store the exdata, and perhaps an "initialized" flag within that memory. the exdata value may be allocated later on with CRYPTO_alloc_ex_data(), or may be set by calling CRYPTO_set_ex_data(). iconic behavior honestly ⭐

when a structure is free'd (such as SSL_CTX_free()) then the free_func() is called for every defined index. again, the state of the parent structure is not guaranteed. and the free_func() may be called with a NULL pointer. 😬

both new_func() and free_func() take the same parameters:

  • parent — the pointer to the structure that contains the exdata
  • ptr — the current exdata item; for new_func() this will typically be NULL
  • r — a pointer to the exdata field of the object
  • idx — the index, and it's the value returned when the callbacks were initially registered via CRYPTO_get_ex_new_index(); you can use it if the same callback handles different types of exdata

dup_func() is called when a structure is being copied. this is only done for SSL, SSL_SESSION, EC_KEY objects and BIO chains via BIO_dup_chain(). the to and from parameters are pointers to the destination and source CRYPTO_EX_DATA structures, respectively. the *from_d parameter is a pointer to the source exdata. when the dup_func() returns, the value in *from_d is copied to the destination ex_data. if the pointer contained in *pptr is not modified by the dup_func(), then both to and from will point to the same data 👀 the idx, argl and argp parameters are as described for the other two callbacks. and if the dup_func() returns 0 the whole CRYPTO_dup_ex_data() will fail 💀

🎀 RETURN VALUES 🎀

  • CRYPTO_get_ex_new_index() returns a new index, or -1 on failure
  • CRYPTO_free_ex_index(), CRYPTO_alloc_ex_data() and CRYPTO_set_ex_data() return 1 on success or 0 on failure
  • CRYPTO_get_ex_data() returns the application data or NULL on failure — but note that NULL may be a valid value, so like, don't panic 🙈
  • dup_func() should return 0 for failure and 1 for success

🌈 HISTORY 🌈

  • CRYPTO_alloc_ex_data() was added in OpenSSL 3.0 ✨
  • the signature of the dup_func() callback was changed in OpenSSL 3.0 to use the type void ** for from_d. previously this parameter was of type void *
  • support for ENGINE "exdata" was deprecated in OpenSSL 3.0 🫠

Copyright 2015-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

and that's the whole page bestie, you ate 💅 version 3.5.6, dated 2026-04-07, CRYPTO_GET_EX_NEW_INDEX(3ossl) — now go attach some exdata, mwah 🫶💖

📦 where this page comes from