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)

doc/internal/man3/cms_add1_signing_cert.pod

@@ -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
 

doc/man1/openssl.pod

@@ -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.

doc/man3/EVP_DigestInit.pod

@@ -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)>

doc/man3/EVP_DigestSignInit.pod

@@ -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

doc/man3/EVP_DigestVerifyInit.pod

@@ -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

doc/man3/EVP_SignInit.pod

@@ -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
 

doc/man3/EVP_VerifyInit.pod

@@ -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
 

doc/man3/OPENSSL_init_crypto.pod

@@ -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

doc/man3/SRP_VBASE_new.pod

@@ -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)>

doc/man3/SRP_create_verifier.pod

@@ -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)>
 

doc/man3/SRP_user_pwd_new.pod

@@ -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)>

doc/man3/SSL_CIPHER_get_name.pod

@@ -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
 

doc/man3/SSL_CONF_cmd.pod

@@ -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>
 

doc/man3/SSL_CTX_set_cipher_list.pod

@@ -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
 

doc/man3/SSL_CTX_set_options.pod

@@ -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
 

doc/man3/SSL_CTX_set_srp_password.pod

@@ -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)>
 

doc/man3/SSL_CTX_set_tmp_dh_callback.pod

@@ -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
 

doc/man3/SSL_CTX_set_tmp_ecdh.pod

@@ -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
 

doc/man3/SSL_get_verify_result.pod

@@ -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
 

doc/man3/SSL_set_verify_result.pod

@@ -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
 

doc/man3/X509_LOOKUP_hash_dir.pod

@@ -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
 

doc/man3/X509_VERIFY_PARAM_set_flags.pod

@@ -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
 

doc/man3/X509_check_issued.pod

@@ -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
 

doc/man3/X509_verify_cert.pod

@@ -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
 

doc/man5/config.pod

@@ -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
 

doc/man5/x509v3_config.pod

@@ -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

doc/man7/Ed25519.pod

@@ -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.
 

doc/man7/SM2.pod

@@ -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
 

util/find-doc-nits

@@ -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;