Fix L<xxx(1)> links to be L<openssl-xxx(1)>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10328)
This commit is contained in:
Rich Salz 2019-11-01 16:26:05 -04:00 committed by Dr. Matthias St. Pierre
parent db30f43242
commit 1903a9b77a
29 changed files with 51 additions and 41 deletions

View File

@ -27,7 +27,7 @@ which updates Section 5.4 of RFC 2634.
This attribute is mandatory to make a CMS compliant with CAdES-BES
(European Standard ETSI EN 319 122-1 V1.1.1).
For a fuller description see L<cms(1)>).
For a fuller description see L<openssl-cms(1)>).
=head1 RETURN VALUES

View File

@ -49,7 +49,7 @@ the SYNOPSIS above), each of which often has a wealth of options and arguments
(I<command_opts> and I<command_args> in the SYNOPSIS).
Detailed documentation and use cases for most standard subcommands are available
(e.g., L<x509(1)> or L<openssl-x509(1)>).
(e.g., L<openssl-x509(1)>).
Many commands use an external configuration file for some or all of their
arguments and have a B<-config> option to specify that file.

View File

@ -591,7 +591,7 @@ digest name passed on the command line.
=head1 SEE ALSO
L<EVP_MD_meth_new(3)>,
L<dgst(1)>,
L<openssl-dgst(1)>,
L<evp(7)>,
L<OSSL_PROVIDER(3)>,
L<OSSL_PARAM(3)>

View File

@ -174,7 +174,7 @@ L<EVP_DigestVerifyInit(3)>,
L<EVP_DigestInit(3)>,
L<evp(7)>, L<HMAC(3)>, L<MD2(3)>,
L<MD5(3)>, L<MDC2(3)>, L<RIPEMD160(3)>,
L<SHA1(3)>, L<dgst(1)>,
L<SHA1(3)>, L<openssl-dgst(1)>,
L<RAND(7)>
=head1 HISTORY

View File

@ -163,7 +163,7 @@ L<EVP_DigestSignInit(3)>,
L<EVP_DigestInit(3)>,
L<evp(7)>, L<HMAC(3)>, L<MD2(3)>,
L<MD5(3)>, L<MDC2(3)>, L<RIPEMD160(3)>,
L<SHA1(3)>, L<dgst(1)>,
L<SHA1(3)>, L<openssl-dgst(1)>,
L<RAND(7)>
=head1 HISTORY

View File

@ -99,7 +99,7 @@ L<EVP_VerifyInit(3)>,
L<EVP_DigestInit(3)>,
L<evp(7)>, L<HMAC(3)>, L<MD2(3)>,
L<MD5(3)>, L<MDC2(3)>, L<RIPEMD160(3)>,
L<SHA1(3)>, L<dgst(1)>
L<SHA1(3)>, L<openssl-dgst(1)>
=head1 COPYRIGHT

View File

@ -81,7 +81,7 @@ L<EVP_SignInit(3)>,
L<EVP_DigestInit(3)>,
L<evp(7)>, L<HMAC(3)>, L<MD2(3)>,
L<MD5(3)>, L<MDC2(3)>, L<RIPEMD160(3)>,
L<SHA1(3)>, L<dgst(1)>
L<SHA1(3)>, L<openssl-dgst(1)>
=head1 COPYRIGHT

View File

@ -197,7 +197,7 @@ Attempts to call OPENSSL_init_crypto() will fail and an ERR_R_INIT_FAIL error
will be added to the error stack. Note that because initialisation has failed
OpenSSL error strings will not be available, only an error code. This code can
be put through the openssl errstr command line application to produce a human
readable error (see L<errstr(1)>).
readable error (see L<openssl-errstr(1)>).
The OPENSSL_atexit() function enables the registration of a
function to be called during OPENSSL_cleanup(). Stop handlers are

View File

@ -43,7 +43,7 @@ The verifier file is a text file containing multiple entries, whose format is:
flag base64(verifier) base64(salt) username gNid userinfo(optional)
where the flag can be 'V' (valid) or 'R' (revoked).
Note that the base64 encoding used here is non-standard so it is recommended
to use L<srp(1)> to generate this file.
to use L<openssl-srp(1)> to generate this file.
The SRP_VBASE_add0_user() function adds the B<user_pwd> verifier information
to the B<vb> structure. See L<SRP_user_pwd_new(3)> to create and populate this
@ -76,7 +76,7 @@ SRP_VBASE_add0_user() returns 1 on success and 0 on failure.
=head1 SEE ALSO
L<srp(1)>,
L<openssl-srp(1)>,
L<SRP_create_verifier(3)>,
L<SRP_user_pwd_new(3)>,
L<SSL_CTX_set_srp_password(3)>

View File

@ -90,7 +90,7 @@ omitted for clarity):
=head1 SEE ALSO
L<srp(1)>,
L<openssl-srp(1)>,
L<SRP_VBASE_new(3)>,
L<SRP_user_pwd_new(3)>

View File

@ -49,7 +49,7 @@ SRP_user_pwd_set0_sv() returns 1 if both B<s> and B<v> are not NULL, 0 otherwise
=head1 SEE ALSO
L<srp(1)>,
L<openssl-srp(1)>,
L<SRP_create_verifier(3)>,
L<SRP_VBASE_new(3)>,
L<SSL_CTX_set_srp_password(3)>

View File

@ -183,7 +183,7 @@ protocol-specific ID.
=head1 SEE ALSO
L<ssl(7)>, L<SSL_get_current_cipher(3)>,
L<SSL_get_ciphers(3)>, L<ciphers(1)>
L<SSL_get_ciphers(3)>, L<openssl-ciphers(1)>
=head1 HISTORY

View File

@ -113,7 +113,7 @@ associated with B<cctx>.
Sets the available ciphersuites for TLSv1.3 to value. This is a simple colon
(":") separated list of TLSv1.3 ciphersuite names in order of preference. This
list will be combined any configured TLSv1.2 and below ciphersuites.
See L<ciphers(1)> for more information.
See L<openssl-ciphers(1)> for more information.
=item B<-cert>
@ -264,7 +264,7 @@ structure is associated with B<cctx>.
Sets the available ciphersuites for TLSv1.3 to B<value>. This is a simple colon
(":") separated list of TLSv1.3 ciphersuite names in order of preference. This
list will be combined any configured TLSv1.2 and below ciphersuites.
See L<ciphers(1)> for more information.
See L<openssl-ciphers(1)> for more information.
=item B<Certificate>

View File

@ -27,7 +27,7 @@ OSSL_default_ciphersuites
SSL_CTX_set_cipher_list() sets the list of available ciphers (TLSv1.2 and below)
for B<ctx> using the control string B<str>. The format of the string is described
in L<ciphers(1)>. The list of ciphers is inherited by all
in L<openssl-ciphers(1)>. The list of ciphers is inherited by all
B<ssl> objects created from B<ctx>. This function does not impact TLSv1.3
ciphersuites. Use SSL_CTX_set_ciphersuites() to configure those.
@ -111,7 +111,7 @@ ciphersuite list was configured, and 0 otherwise.
L<ssl(7)>, L<SSL_get_ciphers(3)>,
L<SSL_CTX_use_certificate(3)>,
L<SSL_CTX_set_tmp_dh_callback(3)>,
L<ciphers(1)>
L<openssl-ciphers(1)>
=head1 HISTORY

View File

@ -364,7 +364,7 @@ secure renegotiation and 0 if it does not.
L<ssl(7)>, L<SSL_new(3)>, L<SSL_clear(3)>,
L<SSL_CTX_set_tmp_dh_callback(3)>,
L<SSL_CTX_set_min_proto_version(3)>,
L<dhparam(1)>
L<openssl-dhparam(1)>
=head1 HISTORY

View File

@ -76,7 +76,7 @@ and the extra argument B<arg> set by SSL_CTX_set_srp_cb_arg().
This callback should setup the server for the key exchange by calling
SSL_set_srp_server_param() with the appropriate parameters for the received
username. The username can be obtained by calling SSL_get_srp_username().
See L<SRP_VBASE_init(3)> to parse the verifier file created by L<srp(1)> or
See L<SRP_VBASE_init(3)> to parse the verifier file created by L<openssl-srp(1)> or
L<SRP_create_verifier(3)> to generate it.
The callback should return B<SSL_ERROR_NONE> to proceed with the server key exchange,
B<SSL3_AL_FATAL> for a fatal error or any value < 0 for a retryable error.
@ -197,7 +197,7 @@ Setup SRP server with verifier file:
=head1 SEE ALSO
L<ssl(7)>,
L<srp(1)>,
L<openssl-srp(1)>,
L<SRP_VBASE_new(3)>,
L<SRP_create_verifier(3)>

View File

@ -59,14 +59,14 @@ DH parameters can be reused, as the actual key is newly generated during
the negotiation. The risk in reusing DH parameters is that an attacker
may specialize on a very often used DH group. Applications should therefore
generate their own DH parameters during the installation process using the
openssl L<dhparam(1)> application. This application
openssl L<openssl-dhparam(1)> application. This application
guarantees that "strong" primes are used.
Files dh2048.pem, and dh4096.pem in the 'apps' directory of the current
version of the OpenSSL distribution contain the 'SKIP' DH parameters,
which use safe primes and were generated verifiably pseudo-randomly.
These files can be converted into C code using the B<-C> option of the
L<dhparam(1)> application. Generation of custom DH
L<openssl-dhparam(1)> application. Generation of custom DH
parameters during installation should still be preferred to stop an
attacker from specializing on a commonly used group. File dh1024.pem
contains old parameters that must not be used by applications.
@ -121,7 +121,7 @@ Code for setting up parameters during server initialization:
L<ssl(7)>, L<SSL_CTX_set_cipher_list(3)>,
L<SSL_CTX_set_options(3)>,
L<ciphers(1)>, L<dhparam(1)>
L<openssl-ciphers(1)>, L<openssl-dhparam(1)>
=head1 COPYRIGHT

View File

@ -36,7 +36,7 @@ on failure.
L<ssl(7)>, L<SSL_CTX_set1_curves(3)>, L<SSL_CTX_set_cipher_list(3)>,
L<SSL_CTX_set_options(3)>, L<SSL_CTX_set_tmp_dh_callback(3)>,
L<ciphers(1)>, L<ecparam(1)>
L<openssl-ciphers(1)>, L<openssl-ecparam(1)>
=head1 COPYRIGHT

View File

@ -44,7 +44,7 @@ The verification succeeded or no peer certificate was presented.
=item Any other value
Documented in L<verify(1)>.
Documented in L<openssl-verify(1)>.
=back
@ -52,7 +52,7 @@ Documented in L<verify(1)>.
L<ssl(7)>, L<SSL_set_verify_result(3)>,
L<SSL_get_peer_certificate(3)>,
L<verify(1)>
L<openssl-verify(1)>
=head1 COPYRIGHT

View File

@ -23,7 +23,7 @@ the verification result of the B<ssl> object. It does not become part of the
established session, so if the session is to be reused later, the original
value will reappear.
The valid codes for B<verify_result> are documented in L<verify(1)>.
The valid codes for B<verify_result> are documented in L<openssl-verify(1)>.
=head1 RETURN VALUES
@ -33,7 +33,7 @@ SSL_set_verify_result() does not provide a return value.
L<ssl(7)>, L<SSL_get_verify_result(3)>,
L<SSL_get_peer_certificate(3)>,
L<verify(1)>
L<openssl-verify(1)>
=head1 COPYRIGHT

View File

@ -85,8 +85,8 @@ with a filename of the form I<hash>.I<N> for a certificate, or
I<hash>.B<r>I<N> for a CRL.
The I<hash> is the value returned by the L<X509_NAME_hash(3)> function applied
to the subject name for certificates or issuer name for CRLs.
The hash can also be obtained via the B<-hash> option of the L<x509(1)> or
L<crl(1)> commands.
The hash can also be obtained via the B<-hash> option of the
L<openssl-x509(1)> or L<openssl-crl(1)> commands.
The .I<N> or .B<r>I<N> suffix is a sequence number that starts at zero, and is
incremented consecutively for each certificate or CRL with the same I<hash>
@ -109,8 +109,8 @@ Note that the hash algorithm used for subject name hashing changed in OpenSSL
1.0.0, and all certificate stores have to be rehashed when moving from OpenSSL
0.9.8 to 1.0.0.
OpenSSL includes a L<rehash(1)> utility which creates symlinks with correct
hashed names for all files with .pem suffix in a given directory.
OpenSSL includes a L<openssl-rehash(1)> utility which creates symlinks with
hashed names for all files with F<.pem> suffix in a given directory.
=head2 OSSL_STORE Method

View File

@ -277,7 +277,7 @@ before searching the provided untrusted certificates.
Local issuer certificates are often more likely to satisfy local security
requirements and lead to a locally trusted root.
This is especially important when some certificates in the trust store have
explicit trust settings (see "TRUST SETTINGS" in L<x509(1)>).
explicit trust settings (see "TRUST SETTINGS" in L<openssl-x509(1)>).
As of OpenSSL 1.1.0 this option is on by default.
The B<X509_V_FLAG_NO_ALT_CHAINS> flag suppresses checking for alternative
@ -364,7 +364,7 @@ L<X509_verify_cert(3)>,
L<X509_check_host(3)>,
L<X509_check_email(3)>,
L<X509_check_ip(3)>,
L<x509(1)>
L<openssl-x509(1)>
=head1 HISTORY

View File

@ -31,7 +31,7 @@ I<issuer> or some B<X509_V_ERR*> constant to indicate an error.
L<X509_verify_cert(3)>,
L<X509_check_ca(3)>,
L<verify(1)>
L<openssl-verify(1)>
=head1 COPYRIGHT

View File

@ -14,7 +14,7 @@ X509_verify_cert - discover and verify X509 certificate chain
The X509_verify_cert() function attempts to discover and validate a
certificate chain based on parameters in B<ctx>. A complete description of
the process is contained in the L<verify(1)> manual page.
the process is contained in the L<openssl-verify(1)> manual page.
=head1 RETURN VALUES

View File

@ -520,7 +520,7 @@ configuration files using that syntax will have to be modified.
=head1 SEE ALSO
L<x509(1)>, L<req(1)>, L<ca(1)>, L<fips_config(5)>
L<openssl-x509(1)>, L<openssl-req(1)>, L<openssl-ca(1)>, L<fips_config(5)>
=head1 COPYRIGHT

View File

@ -529,7 +529,7 @@ will only recognize the last value. This can be worked around by using the form:
=head1 SEE ALSO
L<req(1)>, L<ca(1)>, L<x509(1)>,
L<openssl-req(1)>, L<openssl-ca(1)>, L<openssl-x509(1)>,
L<ASN1_generate_nconf(3)>
=head1 COPYRIGHT

View File

@ -49,7 +49,8 @@ Ed25519 or Ed448 public keys can be set directly using
L<EVP_PKEY_new_raw_public_key(3)> or loaded from a SubjectPublicKeyInfo
structure in a PEM file using L<PEM_read_bio_PUBKEY(3)> (or similar function).
Ed25519 and Ed448 can be tested within L<speed(1)> application since version 1.1.1.
Ed25519 and Ed448 can be tested with the L<openssl-speed(1)> application
since version 1.1.1.
Valid algorithm names are B<ed25519>, B<ed448> and B<eddsa>. If B<eddsa> is
specified, then both Ed25519 and Ed448 are benchmarked.

View File

@ -41,8 +41,8 @@ done by calling:
And normally there is no need to pass a B<pctx> parameter to EVP_DigestSignInit()
or EVP_DigestVerifyInit() in such a scenario.
SM2 can be tested within L<speed(1)> application since version 3.0.0. At current
stage, the only valid algorithm name is B<sm2>.
SM2 can be tested with the L<openssl-speed(1)> application since version 3.0.0.
Currently, the only valid algorithm name is B<sm2>.
=head1 EXAMPLES

View File

@ -458,6 +458,15 @@ sub check {
next if $target =~ m@\([1357]\)/.*>$@; # it has a section/anchor
err($id, "Section missing in $target")
}
# Check for proper links to commands.
while ( $contents =~ /L<([^>]*)\(1\)(?:\/.*)?>/g ) {
my $target = $1;
next if $target =~ /openssl-?/;
next if -f "doc/man1/$target.pod";
# TODO: Filter out "foreign manual" links.
next if $target =~ /ps|apropos|sha1sum|procmail|perl/;
err($id, "Bad command link L<$target(1)>");
}
# Check for proper in-man-3 API links.
while ( $contents =~ /L<([^>]*)\(3\)(?:\/.*)?>/g ) {
my $target = $1;