mirror of
https://github.com/openssl/openssl.git
synced 2025-01-12 13:36:28 +08:00
Standardize on =over 4 and check for it.
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3117)
This commit is contained in:
parent
8c32663cdd
commit
e1271ac221
@ -133,7 +133,7 @@ via B<-macopt> parameter.
|
||||
Passes options to MAC algorithm, specified by B<-mac> key.
|
||||
Following options are supported by both by B<HMAC> and B<gost-mac>:
|
||||
|
||||
=over 8
|
||||
=over 4
|
||||
|
||||
=item B<key:string>
|
||||
|
||||
|
@ -75,7 +75,7 @@ B<list>, or B<no->I<XXX> itself.)
|
||||
|
||||
=head2 Standard Commands
|
||||
|
||||
=over 10
|
||||
=over 4
|
||||
|
||||
=item L<B<asn1parse>|asn1parse(1)>
|
||||
|
||||
@ -268,7 +268,7 @@ X.509 Certificate Data Management.
|
||||
|
||||
=head2 Message Digest Commands
|
||||
|
||||
=over 10
|
||||
=over 4
|
||||
|
||||
=item B<md2>
|
||||
|
||||
@ -314,7 +314,7 @@ SHA-512 Digest
|
||||
|
||||
=head2 Encoding and Cipher Commands
|
||||
|
||||
=over 10
|
||||
=over 4
|
||||
|
||||
=item B<base64>
|
||||
|
||||
@ -365,7 +365,7 @@ This section describes some common options with common behavior.
|
||||
|
||||
=head2 Common Options
|
||||
|
||||
=over 10
|
||||
=over 4
|
||||
|
||||
=item B<-help>
|
||||
|
||||
@ -383,7 +383,7 @@ password argument is given and a password is required then the user is
|
||||
prompted to enter one: this will typically be read from the current
|
||||
terminal with echoing turned off.
|
||||
|
||||
=over 10
|
||||
=over 4
|
||||
|
||||
=item B<pass:password>
|
||||
|
||||
|
@ -107,7 +107,7 @@ By default, B<rehash> only lists each directory as it is processed.
|
||||
|
||||
=head1 ENVIRONMENT
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item B<OPENSSL>
|
||||
|
||||
|
@ -30,7 +30,7 @@ The actual data encoded is determined by the string B<str> and
|
||||
the configuration information. The general format of the string
|
||||
is:
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item B<[modifier,]type[:value]>
|
||||
|
||||
@ -45,7 +45,7 @@ B<value> and B<modifier> are explained below.
|
||||
The supported types are listed below. Unless otherwise specified
|
||||
only the B<ASCII> format is permissible.
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item B<BOOLEAN>, B<BOOL>
|
||||
|
||||
@ -126,7 +126,7 @@ add EXPLICIT or IMPLICIT tagging, add wrappers or to change
|
||||
the string format of the final type and value. The supported
|
||||
formats are documented below.
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item B<EXPLICIT>, B<EXP>
|
||||
|
||||
|
@ -52,7 +52,7 @@ BIO_callback_fn_ex() is the type of the callback function and BIO_callback_fn()
|
||||
is the type of the old format callback function. The meaning of each argument
|
||||
is described below:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item B<b>
|
||||
|
||||
|
@ -32,7 +32,7 @@ This policy may be, for example, that at least one valid SCT is available. To
|
||||
determine this, an SCT's timestamp and signature must be verified.
|
||||
This requires:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item * the public key of the log that issued the SCT
|
||||
|
||||
@ -49,7 +49,7 @@ The above requirements are met using the setters described below.
|
||||
CT_POLICY_EVAL_CTX_new() creates an empty policy evaluation context. This
|
||||
should then be populated using:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item * CT_POLICY_EVAL_CTX_set1_cert() to provide the certificate the SCTs were issued for
|
||||
|
||||
|
@ -82,7 +82,7 @@ With the exception of cipher modes, of which only one may be present,
|
||||
several flags can be or'd together.
|
||||
The available flags are:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item EVP_CIPH_STREAM_CIPHER, EVP_CIPH_ECB_MODE EVP_CIPH_CBC_MODE,
|
||||
EVP_CIPH_CFB_MODE, EVP_CIPH_OFB_MODE, EVP_CIPH_CTR_MODE, EVP_CIPH_GCM_MODE,
|
||||
|
@ -19,7 +19,7 @@ between different code paths to provide optimal performance across wide
|
||||
range of processors. For the moment of this writing following bits are
|
||||
significant:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item bit #4 denoting presence of Time-Stamp Counter.
|
||||
|
||||
@ -86,7 +86,7 @@ are applied, most notably in AES assembler module.
|
||||
The capability vector is further extended with EBX value returned by
|
||||
CPUID with EAX=7 and ECX=0 as input. Following bits are significant:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item bit #64+3 denoting availability of BMI1 instructions, e.g. ANDN;
|
||||
|
||||
|
@ -84,7 +84,7 @@ An internal representation of an SCT can be created in one of two ways.
|
||||
The first option is to create a blank SCT, using SCT_new(), and then populate
|
||||
it using:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item * SCT_set_version() to set the SCT version.
|
||||
|
||||
@ -117,7 +117,7 @@ The former takes ownership, whereas the latter makes a copy.
|
||||
Alternatively, the SCT can be pre-populated from the following data using
|
||||
SCT_new_from_base64():
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item * The SCT version (only SCT_VERSION_V1 is currently supported).
|
||||
|
||||
|
@ -31,7 +31,7 @@ SCT_get_validation_status().
|
||||
|
||||
A CT_POLICY_EVAL_CTX must be provided that specifies:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item * The certificate the SCT was issued for.
|
||||
|
||||
|
@ -64,7 +64,7 @@ This indicates that no version has been set (no connection established).
|
||||
SSL_version() and SSL_client_version() return an integer which could include any of
|
||||
the following:
|
||||
|
||||
=over 5
|
||||
=over 4
|
||||
|
||||
=item SSL3_VERSION
|
||||
|
||||
|
@ -436,7 +436,7 @@ another will be processed after it.
|
||||
|
||||
The following points about the data types might be useful:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item B<ASN1_OBJECT>
|
||||
|
||||
|
@ -16,7 +16,7 @@ other things.
|
||||
|
||||
Normally, this is found as the function I<algorithm>_ecb_encrypt().
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
@ -43,7 +43,7 @@ Normally, this is found as the function I<algorithm>_cbc_encrypt().
|
||||
Be aware that des_cbc_encrypt() is not really DES CBC (it does
|
||||
not update the IV); use des_ncbc_encrypt() instead.
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
@ -75,7 +75,7 @@ An error will affect the current and the following ciphertext blocks.
|
||||
|
||||
Normally, this is found as the function I<algorithm>_cfb_encrypt().
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
@ -122,7 +122,7 @@ An error will affect the current and the following ciphertext variables.
|
||||
|
||||
Normally, this is found as the function I<algorithm>_ofb_encrypt().
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
|
||||
=item *
|
||||
@ -183,7 +183,7 @@ susceptible to a 'known plaintext' attack.
|
||||
|
||||
Normally, this is found as the function I<algorithm>_ecb3_encrypt().
|
||||
|
||||
=over 2
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
@ -218,8 +218,7 @@ ecb mode.
|
||||
|
||||
Normally, this is found as the function I<algorithm>_ede3_cbc_encrypt().
|
||||
|
||||
=over 2
|
||||
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
|
@ -36,7 +36,7 @@ L<EVP_PKEY_print_private(3)>.
|
||||
|
||||
The EVP_PKEY functions support the full range of asymmetric algorithm operations:
|
||||
|
||||
=over
|
||||
=over 4
|
||||
|
||||
=item For key agreement see L<EVP_PKEY_derive(3)>
|
||||
|
||||
|
@ -162,6 +162,8 @@ sub check()
|
||||
if $contents =~ /=head1 NAME.*[<>].*=head1 SYNOPSIS/ms;
|
||||
print "$id Duplicate $1 in L<>\n"
|
||||
if $contents =~ /L<([^>]*)\|([^>]*)>/ && $1 eq $2;
|
||||
print "$id Bad =over $1\n"
|
||||
if $contents =~ /=over([^ ][^4])/;
|
||||
|
||||
# Look for multiple consecutive openssl #include lines.
|
||||
# Consecutive because of files like md5.pod. Sometimes it's okay
|
||||
|
Loading…
Reference in New Issue
Block a user