mirror of
https://github.com/openssl/openssl.git
synced 2025-04-06 20:20:50 +08:00
Link in passphrase-encoding(7) in relevant documentation
Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6179)
This commit is contained in:
parent
491c35324c
commit
8481434439
@ -439,6 +439,9 @@ 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.
|
||||
|
||||
Note that character encoding may be relevant, please see
|
||||
L<passphrase-encoding(7)>.
|
||||
|
||||
=over 4
|
||||
|
||||
=item B<pass:password>
|
||||
|
@ -112,6 +112,14 @@ URI, or if it's a different error (such as memory allocation
|
||||
failures); if the URI was parsable but the scheme unregistered, the
|
||||
top error will have the reason C<OSSL_STORE_R_UNREGISTERED_SCHEME>.
|
||||
|
||||
These functions make no direct assumption regarding the pass phrase received
|
||||
from the password callback.
|
||||
The loaders may make assumptions, however.
|
||||
For example, the B<file:> scheme loader inherits the assumptions made by
|
||||
OpenSSL functionality that handles the different file types; this is mostly
|
||||
relevant for PKCS#12 objects.
|
||||
See L<passphrase-encoding(7)> for further information.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
OSSL_STORE_open() returns a pointer to a B<OSSL_STORE_CTX> on success, or
|
||||
@ -132,7 +140,8 @@ OSSL_STORE_ctrl() and OSSL_STORE_close() returns 1 on success, or 0 on failure.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<ossl_store(7)>, L<OSSL_STORE_INFO(3)>, L<OSSL_STORE_register_loader(3)>
|
||||
L<ossl_store(7)>, L<OSSL_STORE_INFO(3)>, L<OSSL_STORE_register_loader(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
@ -55,6 +55,10 @@ use of BIO_s_file() indicates the use of the operating system stdio
|
||||
functionality, which includes buffering as a feature; BIO_s_fd() is likely
|
||||
to be more appropriate in such cases.
|
||||
|
||||
These functions make no assumption regarding the pass phrase received from the
|
||||
password callback.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
PEM_bytes_read_bio() and PEM_bytes_read_bio_secmem() return 1 for success or
|
||||
@ -63,7 +67,8 @@ PEM_bytes_read_bio() and PEM_bytes_read_bio_secmem() return 1 for success or
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<PEM(3)>,
|
||||
L<PEM_read_bio_ex(3)>
|
||||
L<PEM_read_bio_ex(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
|
@ -110,10 +110,15 @@ Instead, private keys should be stored in PKCS#8 form, with a strong PKCS#5
|
||||
v2.0 PBE.
|
||||
See L<PEM_write_PrivateKey(3)> and L<d2i_PKCS8PrivateKey_bio(3)>.
|
||||
|
||||
PEM_do_header() makes no assumption regarding the pass phrase received from the
|
||||
password callback.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<ERR_peek_last_error(3)>, L<ERR_GET_LIB(3)>,
|
||||
L<d2i_PKCS8PrivateKey_bio(3)>.
|
||||
L<d2i_PKCS8PrivateKey_bio(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -73,6 +73,12 @@ PEM_write_TYPE() writes the PEM encoding of the object B<a> to the file B<fp>.
|
||||
|
||||
PEM_write_bio_TYPE() similarly writes to the BIO B<bp>.
|
||||
|
||||
=head1 NOTES
|
||||
|
||||
These functions make no assumption regarding the pass phrase received from the
|
||||
password callback.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
PEM_read_TYPE() and PEM_read_bio_TYPE() return a pointer to an allocated
|
||||
@ -83,7 +89,8 @@ or zero on error.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<PEM_read(3)>
|
||||
L<PEM_read(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -386,6 +386,10 @@ this:
|
||||
this is a bug because an attempt will be made to reuse the data at B<x>
|
||||
which is an uninitialised pointer.
|
||||
|
||||
These functions make no assumption regarding the pass phrase received from the
|
||||
password callback.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 PEM ENCRYPTION FORMAT
|
||||
|
||||
These old B<PrivateKey> routines use a non standard technique for encryption.
|
||||
@ -465,7 +469,8 @@ as they will be formally deprecated in a future releases.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<EVP_EncryptInit(3)>, L<EVP_BytesToKey(3)>
|
||||
L<EVP_EncryptInit(3)>, L<EVP_BytesToKey(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -60,13 +60,18 @@ should be used.
|
||||
|
||||
B<mac_iter> can be set to -1 and the MAC will then be omitted entirely.
|
||||
|
||||
PKCS12_create() makes assumptions regarding the encoding of the given pass
|
||||
phrase.
|
||||
See L<passphrase-encoding(7)> for more information.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
PKCS12_create() returns a valid B<PKCS12> structure or NULL if an error occurred.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<d2i_PKCS12(3)>
|
||||
L<d2i_PKCS12(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -102,7 +102,8 @@ this function.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<PKCS12_create(3)>, L<ERR_get_error(3)>
|
||||
L<PKCS12_create(3)>, L<ERR_get_error(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -57,7 +57,8 @@ Attributes currently cannot be stored in the private key B<EVP_PKEY> structure.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<d2i_PKCS12(3)>
|
||||
L<d2i_PKCS12(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -52,6 +52,9 @@ Increasing the B<iter> parameter slows down the algorithm which makes it
|
||||
harder for an attacker to perform a brute force attack using a large number
|
||||
of candidate passwords.
|
||||
|
||||
These functions make no assumption regarding the given password.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
PKCS5_PBKDF2_HMAC() and PBKCS5_PBKDF2_HMAC_SHA1() return 1 on success or 0 on error.
|
||||
@ -59,7 +62,8 @@ PKCS5_PBKDF2_HMAC() and PBKCS5_PBKDF2_HMAC_SHA1() return 1 on success or 0 on er
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<evp(7)>, L<RAND_bytes(3)>,
|
||||
L<EVP_BytesToKey(3)>
|
||||
L<EVP_BytesToKey(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
@ -45,6 +45,10 @@ Currently all the functions use BIOs or FILE pointers, there are no functions wh
|
||||
work directly on memory: this can be readily worked around by converting the buffers
|
||||
to memory BIOs, see L<BIO_s_mem(3)> for details.
|
||||
|
||||
These functions make no assumption regarding the pass phrase received from the
|
||||
password callback.
|
||||
It will simply be treated as a byte sequence.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
d2i_PKCS8PrivateKey_bio() and d2i_PKCS8PrivateKey_fp() return a valid B<EVP_PKEY>
|
||||
@ -55,7 +59,8 @@ and i2d_PKCS8PrivateKey_nid_fp() return 1 on success or 0 on error.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<PEM_read_PrivateKey(3)>
|
||||
L<PEM_read_PrivateKey(3)>,
|
||||
L<passphrase-encoding(7)>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user