Clarify! (based on recent mailing-list discussions)

This commit is contained in:
Lutz Jänicke 2001-07-11 15:11:26 +00:00
parent 0410b6c50b
commit bcfca923d4
2 changed files with 9 additions and 0 deletions

View file

@ -40,6 +40,12 @@ then keep it in memory and use it several times. In the last case, the
password could be stored into the B<userdata> storage and the password could be stored into the B<userdata> storage and the
pem_passwd_cb() only returns the password already stored. pem_passwd_cb() only returns the password already stored.
When asking for the password interactively, pem_passwd_cb() can use
B<rwflag> to check, whether an item shall be encrypted (rwflag=1).
In this case the password dialog may ask for the same password twice
for comparison in order to catch typos, that would make decryption
impossible.
Other items in PEM formatting (certificates) can also be encrypted, it is Other items in PEM formatting (certificates) can also be encrypted, it is
however not usual, as certificate information is considered public. however not usual, as certificate information is considered public.

View file

@ -37,6 +37,9 @@ The following mode changes are available:
Allow SSL_write(..., n) to return r with 0 < r < n (i.e. report success Allow SSL_write(..., n) to return r with 0 < r < n (i.e. report success
when just a single record has been written). When not set (the default), when just a single record has been written). When not set (the default),
SSL_write() will only report success once the complete chunk was written. SSL_write() will only report success once the complete chunk was written.
Once SSL_write() returns with r, r bytes have been successfully written
and the next call to SSL_write() must only send the n-r bytes left,
imitating the behaviour of write().
=item SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER =item SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER