docs: Added All NetBSD Manuals

1 files changed, 613 insertions, 0 deletions

diff --git a/static/netbsd/man7/crypto.7 b/static/netbsd/man7/crypto.7
new file mode 100644
index 00000000..8d233cfa
--- /dev/null
+++ b/static/netbsd/man7/crypto.7
@@ -0,0 +1,613 @@
+.\"	$NetBSD: crypto.7,v 1.9 2025/04/16 15:23:17 christos Exp $
+.\"
+.\" -*- mode: troff; coding: utf-8 -*-
+.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
+.ie n \{\
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is >0, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{\
+.    if \nF \{\
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{\
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\" ========================================================================
+.\"
+.IX Title "CRYPTO 7"
+.TH CRYPTO 7 2025-02-11 3.0.16 OpenSSL
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH NAME
+crypto \- OpenSSL cryptographic library
+.SH SYNOPSIS
+.IX Header "SYNOPSIS"
+See the individual manual pages for details.
+.SH DESCRIPTION
+.IX Header "DESCRIPTION"
+The OpenSSL crypto library (\f(CW\*(C`libcrypto\*(C'\fR) implements a wide range of
+cryptographic algorithms used in various Internet standards. The services
+provided by this library are used by the OpenSSL implementations of TLS and
+CMS, and they have also been used to implement many other third party products
+and protocols.
+.PP
+The functionality includes symmetric encryption, public key cryptography, key
+agreement, certificate handling, cryptographic hash functions, cryptographic
+pseudo-random number generators, message authentication codes (MACs), key
+derivation functions (KDFs), and various utilities.
+.SS Algorithms
+.IX Subsection "Algorithms"
+Cryptographic primitives such as the SHA256 digest, or AES encryption are
+referred to in OpenSSL as "algorithms". Each algorithm may have multiple
+implementations available for use. For example the RSA algorithm is available as
+a "default" implementation suitable for general use, and a "fips" implementation
+which has been validated to FIPS standards for situations where that is
+important. It is also possible that a third party could add additional
+implementations such as in a hardware security module (HSM).
+.SS Operations
+.IX Subsection "Operations"
+Different algorithms can be grouped together by their purpose. For example there
+are algorithms for encryption, and different algorithms for digesting data.
+These different groups are known as "operations" in OpenSSL. Each operation
+has a different set of functions associated with it. For example to perform an
+encryption operation using AES (or any other encryption algorithm) you would use
+the encryption functions detailed on the \fBEVP_EncryptInit\fR\|(3) page. Or to
+perform a digest operation using SHA256 then you would use the digesting
+functions on the \fBEVP_DigestInit\fR\|(3) page.
+.SS Providers
+.IX Subsection "Providers"
+A provider in OpenSSL is a component that collects together algorithm
+implementations. In order to use an algorithm you must have at least one
+provider loaded that contains an implementation of it. OpenSSL comes with a
+number of providers and they may also be obtained from third parties. If you
+don't load a provider explicitly (either in program code or via config) then the
+OpenSSL built-in "default" provider will be automatically loaded.
+.SS "Library contexts"
+.IX Subsection "Library contexts"
+A library context can be thought of as a "scope" within which configuration
+options take effect. When a provider is loaded, it is only loaded within the
+scope of a given library context. In this way it is possible for different
+components of a complex application to each use a different library context and
+have different providers loaded with different configuration settings.
+.PP
+If an application does not explicitly create a library context then the
+"default" library context will be used.
+.PP
+Library contexts are represented by the \fBOSSL_LIB_CTX\fR type. Many OpenSSL API
+functions take a library context as a parameter. Applications can always pass
+\&\fBNULL\fR for this parameter to just use the default library context.
+.PP
+The default library context is automatically created the first time it is
+needed. This will automatically load any available configuration file and will
+initialise OpenSSL for use. Unlike in earlier versions of OpenSSL (prior to
+1.1.0) no explicit initialisation steps need to be taken.
+.PP
+Similarly when the application exits the default library context is
+automatically destroyed. No explicit de-initialisation steps need to be taken.
+.PP
+See \fBOSSL_LIB_CTX\fR\|(3) for more information about library contexts.
+See also "ALGORITHM FETCHING".
+.SS "Multi-threaded applications"
+.IX Subsection "Multi-threaded applications"
+As long as OpenSSL has been built with support for threads (the default case
+on most platforms) then most OpenSSL \fIfunctions\fR are thread-safe in the sense
+that it is safe to call the same function from multiple threads at the same
+time. However most OpenSSL \fIdata structures\fR are not thread-safe. For example
+the \fBBIO_write\fR\|(3) and \fBBIO_read\fR\|(3) functions are thread safe. However it
+would not be thread safe to call \fBBIO_write()\fR from one thread while calling
+\&\fBBIO_read()\fR in another where both functions are passed the same \fBBIO\fR object
+since both of them may attempt to make changes to the same \fBBIO\fR object.
+.PP
+There are exceptions to these rules. A small number of functions are not thread
+safe at all. Where this is the case this restriction should be noted in the
+documentation for the function. Similarly some data structures may be partially
+or fully thread safe. For example it is safe to use an \fBOSSL_LIB_CTX\fR in
+multiple threads.
+.PP
+See \fBopenssl\-threads\fR\|(7) for a more detailed discussion on OpenSSL threading
+support.
+.SH "ALGORITHM FETCHING"
+.IX Header "ALGORITHM FETCHING"
+In order to use an algorithm an implementation for it must first be "fetched".
+Fetching is the process of looking through the available implementations,
+applying selection criteria (via a property query string), and finally choosing
+the implementation that will be used.
+.PP
+Two types of fetching are supported by OpenSSL \- explicit fetching and implicit
+fetching.
+.SS "Property query strings"
+.IX Subsection "Property query strings"
+When fetching an algorithm it is possible to specify a property query string to
+guide the selection process. For example a property query string of
+"provider=default" could be used to force the selection to only consider
+algorithm implementations in the default provider.
+.PP
+Property query strings can be specified explicitly as an argument to a function.
+It is also possible to specify a default property query string for the whole
+library context using the \fBEVP_set_default_properties\fR\|(3) or
+\&\fBEVP_default_properties_enable_fips\fR\|(3) functions. Where both
+default properties and function specific properties are specified then they are
+combined. Function specific properties will override default properties where
+there is a conflict.
+.PP
+See \fBproperty\fR\|(7) for more information about properties.
+.SS "Explicit fetching"
+.IX Subsection "Explicit fetching"
+Users of the OpenSSL libraries never query a provider directly for an algorithm
+implementation. Instead, the diverse OpenSSL APIs often have explicit fetching
+functions that do the work, and they return an appropriate algorithm object back
+to the user. These functions usually have the name \f(CW\*(C`APINAME_fetch\*(C'\fR, where
+\&\f(CW\*(C`APINAME\*(C'\fR is the name of the operation. For example \fBEVP_MD_fetch\fR\|(3) can
+be used to explicitly fetch a digest algorithm implementation. The user is
+responsible for freeing the object returned from the \f(CW\*(C`APINAME_fetch\*(C'\fR function
+using \f(CW\*(C`APINAME_free\*(C'\fR when it is no longer needed.
+.PP
+These fetching functions follow a fairly common pattern, where three
+arguments are passed:
+.IP "The library context" 4
+.IX Item "The library context"
+See \fBOSSL_LIB_CTX\fR\|(3) for a more detailed description.
+This may be NULL to signify the default (global) library context, or a
+context created by the user. Only providers loaded in this library context (see
+\&\fBOSSL_PROVIDER_load\fR\|(3)) will be considered by the fetching function. In case
+no provider has been loaded in this library context then the default provider
+will be loaded as a fallback (see \fBOSSL_PROVIDER\-default\fR\|(7)).
+.IP "An identifier" 4
+.IX Item "An identifier"
+For all currently implemented fetching functions this is the algorithm name.
+.IP "A property query string" 4
+.IX Item "A property query string"
+The property query string used to guide selection of the algorithm
+implementation.
+.PP
+The algorithm implementation that is fetched can then be used with other diverse
+functions that use them. For example the \fBEVP_DigestInit_ex\fR\|(3) function takes
+as a parameter an \fBEVP_MD\fR object which may have been returned from an earlier
+call to \fBEVP_MD_fetch\fR\|(3).
+.SS "Implicit fetching"
+.IX Subsection "Implicit fetching"
+OpenSSL has a number of functions that return an algorithm object with no
+associated implementation, such as \fBEVP_sha256\fR\|(3), \fBEVP_aes_128_cbc\fR\|(3),
+\&\fBEVP_get_cipherbyname\fR\|(3) or \fBEVP_get_digestbyname\fR\|(3). These are present for
+compatibility with OpenSSL before version 3.0 where explicit fetching was not
+available.
+.PP
+When they are used with functions like \fBEVP_DigestInit_ex\fR\|(3) or
+\&\fBEVP_CipherInit_ex\fR\|(3), the actual implementation to be used is
+fetched implicitly using default search criteria.
+.PP
+In some cases implicit fetching can also occur when a NULL algorithm parameter
+is supplied. In this case an algorithm implementation is implicitly fetched
+using default search criteria and an algorithm name that is consistent with
+the context in which it is being used.
+.PP
+Functions that revolve around \fBEVP_PKEY_CTX\fR and \fBEVP_PKEY\fR\|(3), such as
+\&\fBEVP_DigestSignInit\fR\|(3) and friends, all fetch the implementations
+implicitly.  Because these functions involve both an operation type (such as
+\&\fBEVP_SIGNATURE\fR\|(3)) and an \fBEVP_KEYMGMT\fR\|(3) for the \fBEVP_PKEY\fR\|(3), they try
+the following:
+.IP 1. 4
+Fetch the operation type implementation from any provider given a library
+context and property string stored in the \fBEVP_PKEY_CTX\fR.
+.Sp
+If the provider of the operation type implementation is different from the
+provider of the \fBEVP_PKEY\fR\|(3)'s \fBEVP_KEYMGMT\fR\|(3) implementation, try to
+fetch a \fBEVP_KEYMGMT\fR\|(3) implementation in the same provider as the operation
+type implementation and export the \fBEVP_PKEY\fR\|(3) to it (effectively making a
+temporary copy of the original key).
+.Sp
+If anything in this step fails, the next step is used as a fallback.
+.IP 2. 4
+As a fallback, try to fetch the operation type implementation from the same
+provider as the original \fBEVP_PKEY\fR\|(3)'s \fBEVP_KEYMGMT\fR\|(3), still using the
+property string from the \fBEVP_PKEY_CTX\fR.
+.SS Performance
+.IX Subsection "Performance"
+If you perform the same operation many times then it is recommended to use
+"Explicit fetching" to prefetch an algorithm once initially,
+and then pass this created object to any operations that are currently
+using "Implicit fetching".
+See an example of Explicit fetching in "USING ALGORITHMS IN APPLICATIONS".
+.PP
+Prior to OpenSSL 3.0, constant method tables (such as \fBEVP_sha256()\fR) were used
+directly to access methods. If you pass one of these convenience functions
+to an operation the fixed methods are ignored, and only the name is used to
+internally fetch methods from a provider.
+.PP
+If the prefetched object is not passed to operations, then any implicit
+fetch will use the internally cached prefetched object, but it will
+still be slower than passing the prefetched object directly.
+.PP
+Fetching via a provider offers more flexibility, but it is slower than the
+old method, since it must search for the algorithm in all loaded providers,
+and then populate the method table using provider supplied methods.
+Internally OpenSSL caches similar algorithms on the first fetch
+(so loading a digest caches all digests).
+.PP
+The following methods can be used for prefetching:
+.IP \fBEVP_MD_fetch\fR\|(3) 4
+.IX Item "EVP_MD_fetch"
+.PD 0
+.IP \fBEVP_CIPHER_fetch\fR\|(3) 4
+.IX Item "EVP_CIPHER_fetch"
+.IP \fBEVP_KDF_fetch\fR\|(3) 4
+.IX Item "EVP_KDF_fetch"
+.IP \fBEVP_MAC_fetch\fR\|(3) 4
+.IX Item "EVP_MAC_fetch"
+.IP \fBEVP_KEM_fetch\fR\|(3) 4
+.IX Item "EVP_KEM_fetch"
+.IP \fBOSSL_ENCODER_fetch\fR\|(3) 4
+.IX Item "OSSL_ENCODER_fetch"
+.IP \fBOSSL_DECODER_fetch\fR\|(3) 4
+.IX Item "OSSL_DECODER_fetch"
+.IP \fBEVP_RAND_fetch\fR\|(3) 4
+.IX Item "EVP_RAND_fetch"
+.PD
+.PP
+The following methods are used internally when performing operations:
+.IP \fBEVP_KEYMGMT_fetch\fR\|(3) 4
+.IX Item "EVP_KEYMGMT_fetch"
+.PD 0
+.IP \fBEVP_KEYEXCH_fetch\fR\|(3) 4
+.IX Item "EVP_KEYEXCH_fetch"
+.IP \fBEVP_SIGNATURE_fetch\fR\|(3) 4
+.IX Item "EVP_SIGNATURE_fetch"
+.IP \fBOSSL_STORE_LOADER_fetch\fR\|(3) 4
+.IX Item "OSSL_STORE_LOADER_fetch"
+.PD
+.PP
+See \fBOSSL_PROVIDER\-default\fR\|(7), <\fBOSSL_PROVIDER\-fips\fR\|(7)> and
+<\fBOSSL_PROVIDER\-legacy\fR\|(7)>for a list of algorithm names that
+can be fetched.
+.SH "FETCHING EXAMPLES"
+.IX Header "FETCHING EXAMPLES"
+The following section provides a series of examples of fetching algorithm
+implementations.
+.PP
+Fetch any available implementation of SHA2\-256 in the default context. Note
+that some algorithms have aliases. So "SHA256" and "SHA2\-256" are synonymous:
+.PP
+.Vb 3
+\& EVP_MD *md = EVP_MD_fetch(NULL, "SHA2\-256", NULL);
+\& ...
+\& EVP_MD_free(md);
+.Ve
+.PP
+Fetch any available implementation of AES\-128\-CBC in the default context:
+.PP
+.Vb 3
+\& EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, "AES\-128\-CBC", NULL);
+\& ...
+\& EVP_CIPHER_free(cipher);
+.Ve
+.PP
+Fetch an implementation of SHA2\-256 from the default provider in the default
+context:
+.PP
+.Vb 3
+\& EVP_MD *md = EVP_MD_fetch(NULL, "SHA2\-256", "provider=default");
+\& ...
+\& EVP_MD_free(md);
+.Ve
+.PP
+Fetch an implementation of SHA2\-256 that is not from the default provider in the
+default context:
+.PP
+.Vb 3
+\& EVP_MD *md = EVP_MD_fetch(NULL, "SHA2\-256", "provider!=default");
+\& ...
+\& EVP_MD_free(md);
+.Ve
+.PP
+Fetch an implementation of SHA2\-256 from the default provider in the specified
+context:
+.PP
+.Vb 3
+\& EVP_MD *md = EVP_MD_fetch(ctx, "SHA2\-256", "provider=default");
+\& ...
+\& EVP_MD_free(md);
+.Ve
+.PP
+Load the legacy provider into the default context and then fetch an
+implementation of WHIRLPOOL from it:
+.PP
+.Vb 2
+\& /* This only needs to be done once \- usually at application start up */
+\& OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy");
+\&
+\& EVP_MD *md = EVP_MD_fetch(NULL, "WHIRLPOOL", "provider=legacy");
+\& ...
+\& EVP_MD_free(md);
+.Ve
+.PP
+Note that in the above example the property string "provider=legacy" is optional
+since, assuming no other providers have been loaded, the only implementation of
+the "whirlpool" algorithm is in the "legacy" provider. Also note that the
+default provider should be explicitly loaded if it is required in addition to
+other providers:
+.PP
+.Vb 3
+\& /* This only needs to be done once \- usually at application start up */
+\& OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy");
+\& OSSL_PROVIDER *default = OSSL_PROVIDER_load(NULL, "default");
+\&
+\& EVP_MD *md_whirlpool = EVP_MD_fetch(NULL, "whirlpool", NULL);
+\& EVP_MD *md_sha256 = EVP_MD_fetch(NULL, "SHA2\-256", NULL);
+\& ...
+\& EVP_MD_free(md_whirlpool);
+\& EVP_MD_free(md_sha256);
+.Ve
+.SH "OPENSSL PROVIDERS"
+.IX Header "OPENSSL PROVIDERS"
+OpenSSL comes with a set of providers.
+.PP
+The algorithms available in each of these providers may vary due to build time
+configuration options. The \fBopenssl\-list\fR\|(1) command can be used to list the
+currently available algorithms.
+.PP
+The names of the algorithms shown from \fBopenssl\-list\fR\|(1) can be used as an
+algorithm identifier to the appropriate fetching function. Also see the provider
+specific manual pages linked below for further details about using the
+algorithms available in each of the providers.
+.PP
+As well as the OpenSSL providers third parties can also implement providers.
+For information on writing a provider see \fBprovider\fR\|(7).
+.SS "Default provider"
+.IX Subsection "Default provider"
+The default provider is built in as part of the \fIlibcrypto\fR library and
+contains all of the most commonly used algorithm implementations. Should it be
+needed (if other providers are loaded and offer implementations of the same
+algorithms), the property query string "provider=default" can be used as a
+search criterion for these implementations.  The default provider includes all
+of the functionality in the base provider below.
+.PP
+If you don't load any providers at all then the "default" provider will be
+automatically loaded. If you explicitly load any provider then the "default"
+provider would also need to be explicitly loaded if it is required.
+.PP
+See \fBOSSL_PROVIDER\-default\fR\|(7).
+.SS "Base provider"
+.IX Subsection "Base provider"
+The base provider is built in as part of the \fIlibcrypto\fR library and contains
+algorithm implementations for encoding and decoding for OpenSSL keys.
+Should it be needed (if other providers are loaded and offer
+implementations of the same algorithms), the property query string
+"provider=base" can be used as a search criterion for these implementations.
+Some encoding and decoding algorithm implementations are not FIPS algorithm
+implementations in themselves but support algorithms from the FIPS provider and
+are allowed for use in "FIPS mode". The property query string "fips=yes" can be
+used to select such algorithms.
+.PP
+See \fBOSSL_PROVIDER\-base\fR\|(7).
+.SS "FIPS provider"
+.IX Subsection "FIPS provider"
+The FIPS provider is a dynamically loadable module, and must therefore
+be loaded explicitly, either in code or through OpenSSL configuration
+(see \fBconfig\fR\|(5)). It contains algorithm implementations that have been
+validated according to the FIPS 140\-2 standard. Should it be needed (if other
+providers are loaded and offer implementations of the same algorithms), the
+property query string "provider=fips" can be used as a search criterion for
+these implementations. All approved algorithm implementations in the FIPS
+provider can also be selected with the property "fips=yes". The FIPS provider
+may also contain non-approved algorithm implementations and these can be
+selected with the property "fips=no".
+.PP
+See \fBOSSL_PROVIDER\-FIPS\fR\|(7) and \fBfips_module\fR\|(7).
+.SS "Legacy provider"
+.IX Subsection "Legacy provider"
+The legacy provider is a dynamically loadable module, and must therefore
+be loaded explicitly, either in code or through OpenSSL configuration
+(see \fBconfig\fR\|(5)). It contains algorithm implementations that are considered
+insecure, or are no longer in common use such as MD2 or RC4. Should it be needed
+(if other providers are loaded and offer implementations of the same algorithms),
+the property "provider=legacy" can be used as a search criterion for these
+implementations.
+.PP
+See \fBOSSL_PROVIDER\-legacy\fR\|(7).
+.SS "Null provider"
+.IX Subsection "Null provider"
+The null provider is built in as part of the \fIlibcrypto\fR library. It contains
+no algorithms in it at all. When fetching algorithms the default provider will
+be automatically loaded if no other provider has been explicitly loaded. To
+prevent that from happening you can explicitly load the null provider.
+.PP
+See \fBOSSL_PROVIDER\-null\fR\|(7).
+.SH "USING ALGORITHMS IN APPLICATIONS"
+.IX Header "USING ALGORITHMS IN APPLICATIONS"
+Cryptographic algorithms are made available to applications through use of the
+"EVP" APIs. Each of the various operations such as encryption, digesting,
+message authentication codes, etc., have a set of EVP function calls that can
+be invoked to use them. See the \fBevp\fR\|(7) page for further details.
+.PP
+Most of these follow a common pattern. A "context" object is first created. For
+example for a digest operation you would use an \fBEVP_MD_CTX\fR, and for an
+encryption/decryption operation you would use an \fBEVP_CIPHER_CTX\fR. The
+operation is then initialised ready for use via an "init" function \- optionally
+passing in a set of parameters (using the \fBOSSL_PARAM\fR\|(3) type) to configure how
+the operation should behave. Next data is fed into the operation in a series of
+"update" calls. The operation is finalised using a "final" call which will
+typically provide some kind of output. Finally the context is cleaned up and
+freed.
+.PP
+The following shows a complete example for doing this process for digesting
+data using SHA256. The process is similar for other operations such as
+encryption/decryption, signatures, message authentication codes, etc.
+.PP
+.Vb 4
+\& #include <stdio.h>
+\& #include <openssl/evp.h>
+\& #include <openssl/bio.h>
+\& #include <openssl/err.h>
+\&
+\& int main(void)
+\& {
+\&     EVP_MD_CTX *ctx = NULL;
+\&     EVP_MD *sha256 = NULL;
+\&     const unsigned char msg[] = {
+\&         0x00, 0x01, 0x02, 0x03
+\&     };
+\&     unsigned int len = 0;
+\&     unsigned char *outdigest = NULL;
+\&     int ret = 1;
+\&
+\&     /* Create a context for the digest operation */
+\&     ctx = EVP_MD_CTX_new();
+\&     if (ctx == NULL)
+\&         goto err;
+\&
+\&     /*
+\&      * Fetch the SHA256 algorithm implementation for doing the digest. We\*(Aqre
+\&      * using the "default" library context here (first NULL parameter), and
+\&      * we\*(Aqre not supplying any particular search criteria for our SHA256
+\&      * implementation (second NULL parameter). Any SHA256 implementation will
+\&      * do.
+\&      * In a larger application this fetch would just be done once, and could
+\&      * be used for multiple calls to other operations such as EVP_DigestInit_ex().
+\&      */
+\&     sha256 = EVP_MD_fetch(NULL, "SHA256", NULL);
+\&     if (sha256 == NULL)
+\&         goto err;
+\&
+\&    /* Initialise the digest operation */
+\&    if (!EVP_DigestInit_ex(ctx, sha256, NULL))
+\&        goto err;
+\&
+\&     /*
+\&      * Pass the message to be digested. This can be passed in over multiple
+\&      * EVP_DigestUpdate calls if necessary
+\&      */
+\&     if (!EVP_DigestUpdate(ctx, msg, sizeof(msg)))
+\&         goto err;
+\&
+\&     /* Allocate the output buffer */
+\&     outdigest = OPENSSL_malloc(EVP_MD_get_size(sha256));
+\&     if (outdigest == NULL)
+\&         goto err;
+\&
+\&     /* Now calculate the digest itself */
+\&     if (!EVP_DigestFinal_ex(ctx, outdigest, &len))
+\&         goto err;
+\&
+\&     /* Print out the digest result */
+\&     BIO_dump_fp(stdout, outdigest, len);
+\&
+\&     ret = 0;
+\&
+\&  err:
+\&     /* Clean up all the resources we allocated */
+\&     OPENSSL_free(outdigest);
+\&     EVP_MD_free(sha256);
+\&     EVP_MD_CTX_free(ctx);
+\&     if (ret != 0)
+\&        ERR_print_errors_fp(stderr);
+\&     return ret;
+\& }
+.Ve
+.SH CONFIGURATION
+.IX Header "CONFIGURATION"
+By default OpenSSL will load a configuration file when it is first used. This
+will set up various configuration settings within the default library context.
+Applications that create their own library contexts may optionally configure
+them with a config file using the \fBOSSL_LIB_CTX_load_config\fR\|(3) function.
+.PP
+The configuration file can be used to automatically load providers and set up
+default property query strings.
+.PP
+For information on the OpenSSL configuration file format see \fBconfig\fR\|(5).
+.SH "ENCODING AND DECODING KEYS"
+.IX Header "ENCODING AND DECODING KEYS"
+Many algorithms require the use of a key. Keys can be generated dynamically
+using the EVP APIs (for example see \fBEVP_PKEY_Q_keygen\fR\|(3)). However it is often
+necessary to save or load keys (or their associated parameters) to or from some
+external format such as PEM or DER (see \fBopenssl\-glossary\fR\|(7)). OpenSSL uses
+encoders and decoders to perform this task.
+.PP
+Encoders and decoders are just algorithm implementations in the same way as
+any other algorithm implementation in OpenSSL. They are implemented by
+providers. The OpenSSL encoders and decoders are available in the default
+provider. They are also duplicated in the base provider.
+.PP
+For information about encoders see \fBOSSL_ENCODER_CTX_new_for_pkey\fR\|(3). For
+information about decoders see \fBOSSL_DECODER_CTX_new_for_pkey\fR\|(3).
+.SH "LIBRARY CONVENTIONS"
+.IX Header "LIBRARY CONVENTIONS"
+Many OpenSSL functions that "get" or "set" a value follow a naming convention
+using the numbers \fB0\fR and \fB1\fR, i.e. "get0", "get1", "set0" and "set1". This
+can also apply to some functions that "add" a value to an existing set, i.e.
+"add0" and "add1".
+.PP
+For example the functions:
+.PP
+.Vb 2
+\& int X509_CRL_add0_revoked(X509_CRL *crl, X509_REVOKED *rev);
+\& int X509_add1_trust_object(X509 *x, const ASN1_OBJECT *obj);
+.Ve
+.PP
+In the \fB0\fR version the ownership of the object is passed to (for an add or set)
+or retained by (for a get) the parent object. For example after calling the
+\&\fBX509_CRL_add0_revoked()\fR function above, ownership of the \fIrev\fR object is passed
+to the \fIcrl\fR object. Therefore, after calling this function \fIrev\fR should not
+be freed directly. It will be freed implicitly when \fIcrl\fR is freed.
+.PP
+In the \fB1\fR version the ownership of the object is not passed to or retained by
+the parent object. Instead a copy or "up ref" of the object is performed. So
+after calling the \fBX509_add1_trust_object()\fR function above the application will
+still be responsible for freeing the \fIobj\fR value where appropriate.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fBopenssl\fR\|(1), \fBssl\fR\|(7), \fBevp\fR\|(7), \fBOSSL_LIB_CTX\fR\|(3), \fBopenssl\-threads\fR\|(7),
+\&\fBproperty\fR\|(7), \fBOSSL_PROVIDER\-default\fR\|(7), \fBOSSL_PROVIDER\-base\fR\|(7),
+\&\fBOSSL_PROVIDER\-FIPS\fR\|(7), \fBOSSL_PROVIDER\-legacy\fR\|(7), \fBOSSL_PROVIDER\-null\fR\|(7),
+\&\fBopenssl\-glossary\fR\|(7), \fBprovider\fR\|(7)
+.SH COPYRIGHT
+.IX Header "COPYRIGHT"
+Copyright 2000\-2023 The OpenSSL Project Authors. All Rights Reserved.
+.PP
+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>.