mirror of https://github.com/openssl/openssl
Fix L<> entries without sections
Add sections (almost always "(3)" to L<> references that were missing them. Among other things, this Fixes: #10226 Also remove two references to non-existant manpages that have never existed, and with the 3.0 structure, are unlikely to do so. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10240)
This commit is contained in:
parent
9fcb9702fb
commit
6e4618a0d7
|
@ -252,7 +252,7 @@ And finally, the library functions:
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<ossl_method_construct>
|
||||
L<ossl_method_construct(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -178,7 +178,7 @@ public key.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<OSSL_PARAM_int>, L<OSSL_PARAM>
|
||||
L<OSSL_PARAM_int(3)>, L<OSSL_PARAM(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -149,7 +149,7 @@ cipher list in order of encryption algorithm key length.
|
|||
|
||||
The cipher string B<@SECLEVEL>=I<n> can be used at any point to set the security
|
||||
level to I<n>, which should be a number between zero and five, inclusive.
|
||||
See L<SSL_CTX_set_security_level> for a description of what each level means.
|
||||
See L<SSL_CTX_set_security_level(3)> for a description of what each level means.
|
||||
|
||||
The cipher list can be prefixed with the B<DEFAULT> keyword, which enables
|
||||
the default cipher list as defined below. Unlike cipher strings,
|
||||
|
|
|
@ -77,7 +77,6 @@ file in a format specified by B<-inform>. The output file will be encrypted
|
|||
PKCS#8 format using the specified encryption parameters unless B<-nocrypt>
|
||||
is included.
|
||||
|
||||
|
||||
=item B<-traditional>
|
||||
|
||||
When this option is present and B<-topk8> is not a traditional format private
|
||||
|
|
|
@ -24,7 +24,7 @@ B<-h> I<server_url>
|
|||
=head1 DESCRIPTION
|
||||
|
||||
This command can be used for sending a timestamp request, as specified
|
||||
in B<RFC 3161>, to a timestamp server over HTTP or HTTPS and storing the
|
||||
in RFC 3161, to a timestamp server over HTTP or HTTPS and storing the
|
||||
timestamp response in a file. It cannot be used for creating the requests
|
||||
and verifying responses, you have to use L<openssl-ts(1)> to do that. This
|
||||
command can send several requests to the server without closing the TCP
|
||||
|
@ -121,7 +121,7 @@ The name of an EGD socket to get random data from. (Optional)
|
|||
|
||||
=item I<request> ...
|
||||
|
||||
List of files containing B<RFC 3161> DER-encoded timestamp requests. If no
|
||||
List of files containing RFC 3161 DER-encoded timestamp requests. If no
|
||||
requests are specified only one request will be sent to the server and it will
|
||||
be read from the standard input.
|
||||
(Optional)
|
||||
|
@ -188,7 +188,7 @@ example:
|
|||
L<openssl(1)>,
|
||||
L<openssl-ts(1)>,
|
||||
L<WWW::Curl::Easy>,
|
||||
L<RFC 3161|https://www.rfc-editor.org/rfc/rfc3161.html>
|
||||
L<https://www.rfc-editor.org/rfc/rfc3161.html>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ BIO_get_shutdown() returns the stat of the BIO's shutdown (i.e. BIO_CLOSE) flag.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<bio>, L<BIO_meth_new>
|
||||
L<bio(7)>, L<BIO_meth_new(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -60,7 +60,7 @@ BIO_meth_set_callback_ctrl - Routines to build up BIO methods
|
|||
|
||||
The B<BIO_METHOD> type is a structure used for the implementation of new BIO
|
||||
types. It provides a set of functions used by OpenSSL for the implementation
|
||||
of the various BIO capabilities. See the L<bio> page for more information.
|
||||
of the various BIO capabilities. See the L<bio(7)> page for more information.
|
||||
|
||||
BIO_meth_new() creates a new B<BIO_METHOD> structure. It should be given a
|
||||
unique integer B<type> and a string that represents its B<name>.
|
||||
|
@ -72,7 +72,7 @@ include B<BIO_TYPE_BUFFER> and B<BIO_TYPE_CIPHER>. Filter BIOs should have a
|
|||
type which have the "filter" bit set (B<BIO_TYPE_FILTER>). Source/sink BIOs
|
||||
should have the "source/sink" bit set (B<BIO_TYPE_SOURCE_SINK>). File descriptor
|
||||
based BIOs (e.g. socket, fd, connect, accept etc) should additionally have the
|
||||
"descriptor" bit set (B<BIO_TYPE_DESCRIPTOR>). See the L<BIO_find_type> page for
|
||||
"descriptor" bit set (B<BIO_TYPE_DESCRIPTOR>). See the L<BIO_find_type(3)> page for
|
||||
more information.
|
||||
|
||||
BIO_meth_free() destroys a B<BIO_METHOD> structure and frees up any memory
|
||||
|
@ -108,7 +108,7 @@ application calling BIO_gets(). The parameters for the function have the same
|
|||
meaning as for BIO_gets().
|
||||
|
||||
BIO_meth_get_ctrl() and BIO_meth_set_ctrl() get and set the function used for
|
||||
processing ctrl messages in the BIO respectively. See the L<BIO_ctrl> page for
|
||||
processing ctrl messages in the BIO respectively. See the L<BIO_ctrl(3)> page for
|
||||
more information. This function will be called in response to the application
|
||||
calling BIO_ctrl(). The parameters for the function have the same meaning as for
|
||||
BIO_ctrl().
|
||||
|
@ -146,7 +146,7 @@ The B<BIO_meth_get> functions return the corresponding function pointers.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<bio>, L<BIO_find_type>, L<BIO_ctrl>, L<BIO_read_ex>, L<BIO_new>
|
||||
L<bio(7)>, L<BIO_find_type(3)>, L<BIO_ctrl(3)>, L<BIO_read_ex(3)>, L<BIO_new(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -71,7 +71,7 @@ be written to B<md1> as before.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<bio>
|
||||
L<bio(7)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@ BIO_get_retry_reason() returns the reason for a special condition.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<bio>
|
||||
L<bio(7)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -20,7 +20,8 @@ an ASN1_OBJECT pointer. An application can then decide how to process the
|
|||
CMS_ContentInfo structure based on this value.
|
||||
|
||||
CMS_set1_eContentType() sets the embedded content type of a CMS_ContentInfo
|
||||
structure. It should be called with CMS functions (such as L<CMS_sign>, L<CMS_encrypt>)
|
||||
structure. It should be called with CMS functions (such as L<CMS_sign(3)>,
|
||||
L<CMS_encrypt(3)>)
|
||||
with the B<CMS_PARTIAL>
|
||||
flag and B<before> the structure is finalised, otherwise the results are
|
||||
undefined.
|
||||
|
|
|
@ -25,7 +25,7 @@ logs). The list can be loaded from one or more files and then searched by LogID
|
|||
CTLOG_STORE_new() creates an empty list of CT logs. This is then populated
|
||||
by CTLOG_STORE_load_default_file() or CTLOG_STORE_load_file().
|
||||
CTLOG_STORE_load_default_file() loads from the default file, which is named
|
||||
"ct_log_list.cnf" in OPENSSLDIR (see the output of L<version>). This can be
|
||||
"ct_log_list.cnf" in OPENSSLDIR (see the output of L<openssl-version(1)>). This can be
|
||||
overridden using an environment variable named "CTLOG_FILE".
|
||||
CTLOG_STORE_load_file() loads from a caller-specified file path instead.
|
||||
Both of these functions append any loaded CT logs to the CTLOG_STORE.
|
||||
|
|
|
@ -88,8 +88,7 @@ DSA_meth_set_keygen - Routines to build up DSA methods
|
|||
|
||||
The B<DSA_METHOD> type is a structure used for the provision of custom DSA
|
||||
implementations. It provides a set of functions used by OpenSSL for the
|
||||
implementation of the various DSA capabilities. See the L<dsa> page for more
|
||||
information.
|
||||
implementation of the various DSA capabilities.
|
||||
|
||||
DSA_meth_new() creates a new B<DSA_METHOD> structure. It should be given a
|
||||
unique B<name> and a set of B<flags>. The B<name> should be a NULL terminated
|
||||
|
|
|
@ -49,7 +49,7 @@ be released during the change. It is possible to have DSA keys that only
|
|||
work with certain DSA_METHOD implementations (eg. from an ENGINE module
|
||||
that supports embedded hardware-protected keys), and in such cases
|
||||
attempting to change the DSA_METHOD for the key can have unexpected
|
||||
results. See L<DSA_meth_new> for information on constructing custom DSA_METHOD
|
||||
results. See L<DSA_meth_new(3)> for information on constructing custom DSA_METHOD
|
||||
objects;
|
||||
|
||||
DSA_new_method() allocates and initializes a DSA structure so that B<engine>
|
||||
|
|
|
@ -234,7 +234,7 @@ respective B<cipher> function.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<EVP_EncryptInit>
|
||||
L<EVP_EncryptInit(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -456,7 +456,7 @@ EVP_CIPHER_CTX_rand_key() returns 1 for success.
|
|||
|
||||
All algorithms have a fixed key length unless otherwise stated.
|
||||
|
||||
Refer to L<SEE ALSO> for the full list of ciphers available through the EVP
|
||||
Refer to L</SEE ALSO> for the full list of ciphers available through the EVP
|
||||
interface.
|
||||
|
||||
=over 4
|
||||
|
|
|
@ -95,8 +95,8 @@ general private key without reference to any particular algorithm.
|
|||
|
||||
The structure returned by EVP_PKEY_new() is empty. To add a private or public
|
||||
key to this empty structure use the appropriate functions described in
|
||||
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA>, L<EVP_PKEY_set1_DH> or
|
||||
L<EVP_PKEY_set1_EC_KEY>.
|
||||
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA(3)>, L<EVP_PKEY_set1_DH(3)> or
|
||||
L<EVP_PKEY_set1_EC_KEY(3)>.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
|
@ -109,8 +109,8 @@ EVP_PKEY_get_raw_public_key() return 1 for success and 0 for failure.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA>, L<EVP_PKEY_set1_DH> or
|
||||
L<EVP_PKEY_set1_EC_KEY>
|
||||
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA(3)>, L<EVP_PKEY_set1_DH(3)> or
|
||||
L<EVP_PKEY_set1_EC_KEY(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ The latter adds an error on the error stack.
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<EVP_MD_fetch>
|
||||
L<EVP_MD_fetch(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -532,7 +532,8 @@ CertRepMessage or Revocation Response or error message, or NULL if unset.
|
|||
|
||||
OSSL_CMP_CTX_get_failInfoCode() returns the error code from the failInfo field
|
||||
of the last received CertRepMessage or Revocation Response or error message.
|
||||
This is a bit field and the flags for it are specified in L<cmp.h>.
|
||||
This is a bit field and the flags for it are specified in the header file
|
||||
F<< <openssl/cmp.h> >>.
|
||||
The flags start with OSSL_CMP_CTX_FAILINFO, for example:
|
||||
OSSL_CMP_CTX_FAILINFO_badAlg. Returns -1 if the failInfoCode field is unset.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ grained search of objects.
|
|||
|
||||
OSSL_STORE_supports_search() checks if the loader of the given OSSL_STORE
|
||||
context supports the given search type.
|
||||
See L<OSSL_STORE_SEARCH/SUPPORTED CRITERION TYPES> for information on the
|
||||
See L<OSSL_STORE_SEARCH(3)/SUPPORTED CRITERION TYPES> for information on the
|
||||
supported search criterion types.
|
||||
|
||||
OSSL_STORE_expect() and OSSL_STORE_find I<must> be called before the first
|
||||
|
|
|
@ -125,8 +125,7 @@ RSA_meth_get_multi_prime_keygen, RSA_meth_set_multi_prime_keygen
|
|||
|
||||
The B<RSA_METHOD> type is a structure used for the provision of custom
|
||||
RSA implementations. It provides a set of functions used by OpenSSL
|
||||
for the implementation of the various RSA capabilities. See the L<rsa>
|
||||
page for more information.
|
||||
for the implementation of the various RSA capabilities.
|
||||
|
||||
RSA_meth_new() creates a new B<RSA_METHOD> structure. It should be
|
||||
given a unique B<name> and a set of B<flags>. The B<name> should be a
|
||||
|
|
|
@ -16,7 +16,7 @@ Prints Signed Certificate Timestamps in a human-readable way
|
|||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
SCT_print() prints a single Signed Certificate Timestamp (SCT) to a L<bio> in
|
||||
SCT_print() prints a single Signed Certificate Timestamp (SCT) to a B<BIO> in
|
||||
a human-readable format. SCT_LIST_print() prints an entire list of SCTs in a
|
||||
similar way. A separator can be specified to delimit each SCT in the output.
|
||||
|
||||
|
|
|
@ -110,7 +110,7 @@ SSL_client_hello_get1_extensions_present() returns 1 on success and 0 on failure
|
|||
=head1 SEE ALSO
|
||||
|
||||
L<ssl(7)>, L<SSL_CTX_set_tlsext_servername_callback(3)>,
|
||||
L<SSL_bytes_to_cipher_list>
|
||||
L<SSL_bytes_to_cipher_list(3)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ See L<CTLOG_STORE_new(3)> for the file format.
|
|||
=head1 NOTES
|
||||
|
||||
These functions will not clear the existing CT log list - it will be appended
|
||||
to. To replace the existing list, use L<SSL_CTX_set0_ctlog_store> first.
|
||||
to. To replace the existing list, use L<SSL_CTX_set0_ctlog_store(3)> first.
|
||||
|
||||
If an error occurs whilst parsing a particular log entry in the file, that log
|
||||
entry will be skipped.
|
||||
|
|
|
@ -43,7 +43,7 @@ decryption has been attempted and any session ticket application data is
|
|||
available. If ticket decryption was successful then the B<ss> argument contains
|
||||
the session data. The B<keyname> and B<keyname_len> arguments identify the key
|
||||
used to decrypt the session ticket. The B<status> argument is the result of the
|
||||
ticket decryption. See the L<NOTES> section below for further details. The value
|
||||
ticket decryption. See the L</NOTES> section below for further details. The value
|
||||
of B<arg> is the same as that given to SSL_CTX_set_session_ticket_cb(). The
|
||||
B<dec_cb> callback is defined as type B<SSL_CTX_decrypt_session_ticket_fn>.
|
||||
|
||||
|
@ -168,7 +168,7 @@ failure.
|
|||
The B<gen_cb> callback must return 1 to continue the connection. A return of 0
|
||||
will terminate the connection with an INTERNAL_ERROR alert.
|
||||
|
||||
The B<dec_cb> callback must return a value as described in L<NOTES> above.
|
||||
The B<dec_cb> callback must return a value as described in L</NOTES> above.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@ SSL_alloc_buffers().
|
|||
|
||||
L<SSL_free(3)>, L<SSL_clear(3)>,
|
||||
L<SSL_new(3)>, L<SSL_CTX_set_mode(3)>,
|
||||
L<CRYPTO_set_mem_functions>
|
||||
L<CRYPTO_set_mem_functions(3)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
|
|
@ -65,7 +65,7 @@ yet completed the authentication stage of the handshake.
|
|||
|
||||
Early data has weaker security properties than other data sent over an SSL/TLS
|
||||
connection. In particular the data does not have forward secrecy. There are also
|
||||
additional considerations around replay attacks (see L<REPLAY PROTECTION>
|
||||
additional considerations around replay attacks (see L</REPLAY PROTECTION>
|
||||
below). For these reasons extreme care should be exercised when using early
|
||||
data. For specific details, consult the TLS 1.3 specification.
|
||||
|
||||
|
|
|
@ -19,13 +19,13 @@ decode and encode Signed Certificate Timestamp lists in TLS wire format
|
|||
|
||||
The SCT_LIST and SCT functions are very similar to the i2d and d2i family of
|
||||
functions, except that they convert to and from TLS wire format, as described in
|
||||
RFC 6962. See L<d2i_SCT_LIST> for more information about how the parameters are
|
||||
RFC 6962. See L<d2i_SCT_LIST(3)> for more information about how the parameters are
|
||||
treated and the return values.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
All of the functions have return values consistent with those stated for
|
||||
L<d2i_SCT_LIST> and L<i2d_SCT_LIST>.
|
||||
L<d2i_SCT_LIST(3)> and L<i2d_SCT_LIST(3)>.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ use is defined by the extension code itself: check out the certificate
|
|||
policies extension for an example.
|
||||
|
||||
If an extension type is unsupported then the I<arbitrary> extension syntax
|
||||
must be used, see the L<ARBITRARY EXTENSIONS|/"ARBITRARY EXTENSIONS"> section for more details.
|
||||
must be used, see the L</ARBITRARY EXTENSIONS> section for more details.
|
||||
|
||||
=head1 STANDARD EXTENSIONS
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ parameter to the L<EVP_KDF_derive(3)> function, and MUST match the key
|
|||
length for the chosen cipher or an error is returned. Moreover the
|
||||
constant's length must not exceed the block size of the cipher.
|
||||
Since the KRB5KDF output length depends on the chosen cipher, calling
|
||||
L<EVP_KDF_size()> to obtain the requisite length returns the correct length
|
||||
L<EVP_KDF_size(3)> to obtain the requisite length returns the correct length
|
||||
only after the cipher is set. Prior to that B<EVP_MAX_KEY_LENGTH> is returned.
|
||||
The caller must allocate a buffer of the correct length for the chosen
|
||||
cipher, and pass that buffer to the L<EVP_KDF_derive(3)> function along
|
||||
|
@ -94,7 +94,7 @@ RFC 3961
|
|||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<EVP_KDF>,
|
||||
L<EVP_KDF(3)>,
|
||||
L<EVP_KDF_CTX_new_id(3)>,
|
||||
L<EVP_KDF_CTX_free(3)>,
|
||||
L<EVP_KDF_ctrl(3)>,
|
||||
|
|
|
@ -91,7 +91,7 @@ A context for SSHKDF can be obtained by calling:
|
|||
|
||||
The output length of the SSHKDF derivation is specified via the I<keylen>
|
||||
parameter to the L<EVP_KDF_derive(3)> function.
|
||||
Since the SSHKDF output length is variable, calling L<EVP_KDF-size()>
|
||||
Since the SSHKDF output length is variable, calling L<EVP_KDF_size(3)>
|
||||
to obtain the requisite length is not meaningful. The caller must
|
||||
allocate a buffer of the desired length, and pass that buffer to the
|
||||
L<EVP_KDF_derive(3)> function along with the desired length.
|
||||
|
|
|
@ -447,6 +447,24 @@ sub check {
|
|||
check_section_location($id, $contents, "EXAMPLES", "SEE ALSO");
|
||||
}
|
||||
|
||||
# Make sure every link has a section.
|
||||
while ( $contents =~ /$markup_re/msg ) {
|
||||
my $target = $1;
|
||||
next unless $target =~ /^L</; # Skip if not L<...>, or
|
||||
next if $target =~ /::/; # links to a Perl module, or
|
||||
next if $target =~ m@L</@; # links within the page, or
|
||||
next if $target =~ /^L<https?:/; # is a URL link, or
|
||||
next if $target =~ m@\([1357]\)>$@; # it has a section, or
|
||||
next if $target =~ m@\([1357]\)/.*>$@; # it has a section/anchor
|
||||
err($id, "Section missing in $target")
|
||||
}
|
||||
# Check for proper in-man-3 API links.
|
||||
while ( $contents =~ /L<([^>]*)\(3\)(?:\/.*)?>/g ) {
|
||||
my $target = $1;
|
||||
err($id, "Bad L<$target>")
|
||||
unless $target =~ /^[_[:alpha:]][_[:alnum:]]*$/
|
||||
}
|
||||
|
||||
unless ( $contents =~ /=for openssl generic/ ) {
|
||||
if ( $filename =~ m|man3/| ) {
|
||||
name_synopsis($id, $filename, $contents);
|
||||
|
|
Loading…
Reference in New Issue