summaryrefslogtreecommitdiff
path: root/src/lib/libssl/man/SSL_get_shared_ciphers.3 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Update SSL_get_shared_ciphers() documentation for ssl_lib.c r1.240tb2021-01-091-17/+47
| | | | | | | | | | | | | | | | | | | | | | | From schwarze, who explains: * Even though i wrote the original version of our documentation for this function, i now think the design of this function is so atrocious that it is better to call out the main limitations up front (server side only and silent truncation) rather than first giving the impression that it achieves something it actually doesn't and then later try to row back in a piece-meal manner. * Using a .Bl list for failure conditions in the RETURN VALUES section is no doubt unusual, but the conditions are so numerous and some of them are so surprising that i think it makes sense in this case. If a function is badly designed and has surprising properties, precision and clarity in the description are even more important than usual, and conciseness is better sacrificed. * Adding .Xr SSL_get_ciphers 3 seems helpful. ok beck inoguchi jsing tb
* add missing backlinks to ssl(3)schwarze2019-06-121-2/+4
|
* found a complete archive of SSLeay-0.4 to SSLeay-0.8.1b tarballsschwarze2018-03-271-3/+3
| | | | on the web, so fix up SSLeay HISTORY accordingly
* ssl.h HISTORY up to SSLeay 0.8.1b; researched from OpenSSL gitschwarze2018-03-211-3/+4
|
* Write an SSL_get_shared_ciphers(3) manual from scratch; another oneschwarze2016-12-101-0/+70
where BUGS is longer than DESCRIPTION. The function is listed in ssl(3) and <openssl/ssl.h>, so it's clearly public. The code looks slightly mysterious to me, so it would be welcome if somebody more familiar with TLS protocols could check factual accuracy.