openssl/crypto/err
Richard Levitte 0d003c52d3 SERIALIZER: New API for serialization of objects through providers
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)

The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form.  The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.

We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.

Serializers are selected by method name and a couple of additional
properties:

- format        used to tell what format the output should be in.
                Possibilities could include "format=text",
                "format=pem", "format=der", "format=pem-pkcs1"
                (traditional), "format=der-pkcs1" (traditional)
- type          used to tell exactly what type of data should be
                output, for example "type=public" (the public part of
                a key), "type=private" (the private part of a key),
                "type=domainparams" (domain parameters).

This also adds a passphrase callback function type,
OSSL_PASSPHRASE_CALLBACK, which is a bit like OSSL_CALLBACK, but it
takes a few extra arguments to place the result in.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
2019-11-29 20:54:48 +01:00
..
build.info
err_all.c Cleanup: move remaining providers/common/include/internal/*.h 2019-10-10 14:12:15 +02:00
err_blocks.c Reorganize local header files 2019-09-28 20:26:35 +02:00
err_local.h Reorganize local header files 2019-09-28 20:26:35 +02:00
err_prn.c Check the return from OPENSSL_buf2hexstr() 2019-11-29 14:21:55 +00:00
err.c SERIALIZER: New API for serialization of objects through providers 2019-11-29 20:54:48 +01:00
openssl.ec SERIALIZER: New API for serialization of objects through providers 2019-11-29 20:54:48 +01:00
openssl.txt CORE: ossl_namemap_add_names(): new function to add multiple names 2019-11-29 20:42:12 +01:00
README

Adding new libraries
--------------------

When adding a new sub-library to OpenSSL, assign it a library number
ERR_LIB_XXX, define a macro XXXerr() (both in err.h), add its
name to ERR_str_libraries[] (in crypto/err/err.c), and add
ERR_load_XXX_strings() to the ERR_load_crypto_strings() function
(in crypto/err/err_all.c). Finally, add an entry:

    L      XXX     xxx.h   xxx_err.c

to crypto/err/openssl.ec, and add xxx_err.c to the Makefile.
Running make errors will then generate a file xxx_err.c, and
add all error codes used in the library to xxx.h.

Additionally the library include file must have a certain form.
Typically it will initially look like this:

    #ifndef HEADER_XXX_H
    #define HEADER_XXX_H

    #ifdef __cplusplus
    extern "C" {
    #endif

    /* Include files */

    #include <openssl/bio.h>
    #include <openssl/x509.h>

    /* Macros, structures and function prototypes */


    /* BEGIN ERROR CODES */

The BEGIN ERROR CODES sequence is used by the error code
generation script as the point to place new error codes, any text
after this point will be overwritten when make errors is run.
The closing #endif etc will be automatically added by the script.

The generated C error code file xxx_err.c will load the header
files stdio.h, openssl/err.h and openssl/xxx.h so the
header file must load any additional header files containing any
definitions it uses.