Latest update.
This commit is contained in:
@@ -0,0 +1,56 @@
|
||||
=pod
|
||||
|
||||
=head1 NAME
|
||||
|
||||
EVP_PKEY - an internal description
|
||||
|
||||
=head1 SYNOPSIS
|
||||
|
||||
#include "crypto/evp.h"
|
||||
|
||||
struct evp_pkey_st;
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
I<This is not a complete description yet>
|
||||
|
||||
B<EVP_PKEY> is a complex type that's essentially a container for
|
||||
private/public key key pairs, but has had other uses as well.
|
||||
|
||||
=for comment "uses" could as well be "abuses"...
|
||||
|
||||
It can contain the legacy form of keys -- i.e. pointers to the low
|
||||
level key types, such as B<RSA>, B<DSA> and B<EC> --, but also the
|
||||
provided form of keys -- i.e. pointers to provider side key data.
|
||||
Those two forms are mutually exclusive; an B<EVP_PKEY> instance can't
|
||||
contain both a key in legacy form and in provided form. Regardless of
|
||||
form, this key is commonly refered to as the "origin".
|
||||
|
||||
An B<EVP_PKEY> also contains a cache of provider side copies of the
|
||||
key, each adapted for the provider that is going to use that copy to
|
||||
perform some operation.
|
||||
For a legacy "origin", the B<EVP_PKEY_ASN1_METHOD>'s functions
|
||||
export_to() and dirty_cnt() must be implemented for such caching to be
|
||||
possible. For a provider side "origin", the B<EVP_KEYMGMT>'s function
|
||||
OP_keymgmt_export() must be implemented. In all cases, the receiving
|
||||
B<EVP_KEYMGMT> must have an implemented OP_keygmt_import().
|
||||
|
||||
If such caching isn't supported, the operations that can be performed
|
||||
with that key are limited to the same backend as the "origin" key
|
||||
(ENGINE for legacy "origin" keys, provider for provider side "origin"
|
||||
keys).
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<provider-keymgmt(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
Copyright 2020 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
|
||||
L<https://www.openssl.org/source/license.html>.
|
||||
|
||||
=cut
|
||||
@@ -24,7 +24,7 @@ B<MODULES=> I<name> ...
|
||||
|
||||
B<SCRIPTS=> I<name> ...
|
||||
|
||||
B<DEPEND[>I<item>B<]=> I<otheritem> ...
|
||||
B<DEPEND[>I<items>B<]=> I<otheritem> ...
|
||||
|
||||
B<GENERATE[>I<item>B<]=> I<generator> I<generator-args> ...
|
||||
|
||||
@@ -32,9 +32,9 @@ B<SOURCE[>I<item>B<]=> I<file> ...
|
||||
|
||||
B<SHARED_SOURCE[>I<item>B<]=> I<file> ...
|
||||
|
||||
B<DEFINE[>I<item>B<]=> I<name>[B<=>I<value>] ...
|
||||
B<DEFINE[>I<items>B<]=> I<name>[B<=>I<value>] ...
|
||||
|
||||
B<INCLUDE[>I<item>B<]=> I<dir> ...
|
||||
B<INCLUDE[>I<items>B<]=> I<dir> ...
|
||||
|
||||
B<$>I<VARIABLE>B<=>I<value>
|
||||
|
||||
@@ -122,7 +122,7 @@ syntax is one of:
|
||||
|
||||
=item B<I<KEYWORD>> B<=> I<value> ...
|
||||
|
||||
=item B<I<KEYWORD>[>I<item>B<]> B<=> I<value> ...
|
||||
=item B<I<KEYWORD>[>I<items>B<]> B<=> I<value> ...
|
||||
|
||||
=back
|
||||
|
||||
@@ -154,8 +154,14 @@ F<foo.c> and F<details.c>, and that it depends on the library
|
||||
C<libcookie> (in other words, the library will be included when
|
||||
linking that program together).
|
||||
|
||||
For any indexed statement for which the item hasn't been specified
|
||||
through any plain statement, or where the item exists but the indexed
|
||||
Multiple space separated items are allowed too:
|
||||
|
||||
SOURCE[foo]=foo.c
|
||||
SOURCE[details]=details.c
|
||||
DEPEND[foo details]=libcookie
|
||||
|
||||
For any indexed statement for which the items haven't been specified
|
||||
through any plain statement, or where the items exists but the indexed
|
||||
statement does not apply, the value is simply ignored by the build
|
||||
file generators.
|
||||
|
||||
@@ -169,7 +175,7 @@ variations on how they are treated.
|
||||
=item B<I<KEYWORD>{> I<attrib> | I<attrib>B<=>I<attrib-value> [,...]B<}>
|
||||
B<=> I<value> ...
|
||||
|
||||
=item B<I<KEYWORD>[>I<item>B<]{> I<attrib> | I<attrib>B<=>I<attrib-value>
|
||||
=item B<I<KEYWORD>[>I<items>B<]{> I<attrib> | I<attrib>B<=>I<attrib-value>
|
||||
[,...]B<}> B<=> I<value> ...
|
||||
|
||||
=back
|
||||
@@ -264,6 +270,22 @@ part of is tokenized>.
|
||||
|
||||
I<Variable assignment values are not tokenized.>
|
||||
|
||||
Variable references can be one of:
|
||||
|
||||
=over 4
|
||||
|
||||
=item B<$>I<NAME> or B<${>I<NAME>B<}>
|
||||
|
||||
Simple reference; the variable reference is replaced with its value,
|
||||
verbatim.
|
||||
|
||||
=item B<${>I<NAME>B</>I<str>B</>I<subst>B<}>
|
||||
|
||||
Substitution reference; the variable reference is replaced with its
|
||||
value, modified by replacing all occurences of I<str> with I<subst>.
|
||||
|
||||
=back
|
||||
|
||||
=head2 Scope
|
||||
|
||||
Most of the statement values are accumulated globally from all the
|
||||
@@ -411,15 +433,15 @@ C<noinst>, while the script C<bar> will.
|
||||
|
||||
=over 4
|
||||
|
||||
=item B<DEPEND[>I<item>B<]> B<=> I<file> ...
|
||||
=item B<DEPEND[>I<items>B<]> B<=> I<file> ...
|
||||
|
||||
Collects dependencies, where I<item> depends on the given I<file>s.
|
||||
Collects dependencies, where I<items> depend on the given I<file>s.
|
||||
|
||||
As a special case, the I<item> may be empty, for which the build file
|
||||
As a special case, the I<items> may be empty, for which the build file
|
||||
generators should make the whole build depend on the given I<file>s,
|
||||
rather than some specific I<item>.
|
||||
rather than the specific I<items>.
|
||||
|
||||
The I<item> may be any program, library, module, script, or any
|
||||
The I<items> may be any program, library, module, script, or any
|
||||
filename used as a value anywhere.
|
||||
|
||||
B<DEPEND> statements may have attributes, which apply to each
|
||||
@@ -473,19 +495,19 @@ given with B<LIBS> or B<MODULES>. For libraries, the given filenames
|
||||
are only used for their shared form, so if the item is a library name
|
||||
ending with C<.a>, the filenames will be ignored.
|
||||
|
||||
=item B<DEFINE[>I<item>B<]> B<=> I<name>[B<=>I<value>] ...
|
||||
=item B<DEFINE[>I<items>B<]> B<=> I<name>[B<=>I<value>] ...
|
||||
|
||||
Collects I<name> / I<value> pairs (or just I<name> with no defined
|
||||
value if no I<value> is given) associated with I<item>.
|
||||
value if no I<value> is given) associated with I<items>.
|
||||
|
||||
The build file generators will decide what to do with them. For
|
||||
example, these pairs should become C macro definitions whenever a
|
||||
C<.c> file is built into an object file.
|
||||
|
||||
=item B<INCLUDE[>I<item>B<]> B<=> I<dir> ...
|
||||
=item B<INCLUDE[>I<items>B<]> B<=> I<dir> ...
|
||||
|
||||
Collects inclusion directories that will be used when building the
|
||||
I<item> components (object files and whatever else). This is used at
|
||||
I<items> components (object files and whatever else). This is used at
|
||||
the discretion of the build file generators.
|
||||
|
||||
=back
|
||||
@@ -568,7 +590,7 @@ the exception of conditional statements and variable assignments.
|
||||
|
||||
=item "indexed statement"
|
||||
|
||||
Any F<build.info> statement of the form B<I<KEYWORD>[>I<item>B<]=>I<values>,
|
||||
Any F<build.info> statement of the form B<I<KEYWORD>[>I<items>B<]=>I<values>,
|
||||
with the exception of conditional statements.
|
||||
|
||||
=item "intermediate file"
|
||||
|
||||
Reference in New Issue
Block a user