mirror of
https://github.com/openssl/openssl.git
synced 2025-03-31 20:10:45 +08:00
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:
parent
db30f43242
commit
1903a9b77a
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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)>
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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)>
|
||||
|
@ -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)>
|
||||
|
||||
|
@ -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)>
|
||||
|
@ -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
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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)>
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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;
|
||||
|
Loading…
x
Reference in New Issue
Block a user