Tighten up SSL_get1_supported_ciphers() docs #4284
Conversation
This function is really emulating what would happen in client mode, and does not necessarily reflect what is usable for a server SSL. Make this a bit more explicit, and do some wordsmithing while here.
doc/man3/SSL_get_ciphers.pod
Outdated
| differ from the list of acceptable ciphers when B<ssl> is the server side | ||
| of a connection, as can occur when there is a | ||
| hole in the list of supported protocols or the configured certificates and | ||
| DH parameters limit the usable ciphers. |
There was a problem hiding this comment.
As non-native English speaker I find this unnecessary complex. Since Single sentence in place of three, that suggests stronger causality between client and server lists than there is, which with implied subject [I mean what's subject in "as can occur"?]...
Per Andy's review [to be squashed] [skip ci]
doc/man3/SSL_get_ciphers.pod
Outdated
| the list of ciphers that would be acceptable when acting as a server. | ||
| For example, additional ciphers may be usable by a server if there is | ||
| a hole in the list of supported protocols, and some ciphers may not be | ||
| usable by a server if there is not a corresponding certificate configured. |
There was a problem hiding this comment.
I'm a bit uncomfortable commenting on language [beyond "I find it unnecessary complex"], let alone actually approving commits requests. But does "if there is not a corresponding certificate configured" sound right? Wouldn't "if there is no suitable certificate configured" reflect circumstances better? And may I suggest "gap" instead of "hole", perhaps?
There was a problem hiding this comment.
I am happy to hear your comments on language, and also to respect your reluctance to approve such commits.
Both "suitable" and "gap" sound like improvements to me; thanks.
richsalz
added
the
approval: review pending
[to be squashed] [skip ci]
|
Oh! I expect that commits will be squashed upon merge :-) |
dot-asm
added
approval: done
This function is really emulating what would happen in client mode, and does not necessarily reflect what is usable for a server SSL. Make this a bit more explicit, and do some wordsmithing while here. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from #4284)
|
squashed to e65dfa4 and merged; thanks |
This function is really emulating what would happen in client mode,
and does not necessarily reflect what is usable for a server SSL.
Make this a bit more explicit, and do some wordsmithing while here.
Checklist