On Fri, Jan 26, 2018 at 12:27:16AM +0100, Daniel Gustafsson wrote:
>> On 25 Jan 2018, at 15:07, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> On 1/19/18 13:43, Peter Eisentraut wrote:
>>> Comparing the existing {be,fe}-secure-openssl.c with the proposed
>>> {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed
>>> Apple Secure Transport implementation, I have identified a few more
>>> areas of refactoring that should be done in order to avoid excessive
>>> copy-and-pasting in the new implementations:
>>
>> And here is another place that needs cleaning up, where the OpenSSL API
>> was used directly.
>
> +1 on these cleanups.
Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the
same time please? I think that those should use the generic backend-side
APIs as well. sslinfo depends heavily on OpenSSL, OK, but if possible
getting this code more generic will help users of sslinfo to get
something partially working with other SSL implementations natively.
> Regarding this hunk:
>
> extern int be_tls_get_cipher_bits(Port *port);
> extern bool be_tls_get_compression(Port *port);
> -extern void be_tls_get_version(Port *port, char *ptr, size_t len);
> -extern void be_tls_get_cipher(Port *port, char *ptr, size_t len);
> +extern const char *be_tls_get_version(Port *port);
> +extern const char *be_tls_get_cipher(Port *port);
> extern void be_tls_get_peerdn_name(Port *port, char *ptr, size_t len);
>
> While only tangentially related to the issue this patch solves, converting
> be_tls_get_peerdn_name() to return const char * seems reasonable too to keep
> the API consistent.
Why? This is not used for error message generation yet. We could always
change the API as needed later on.
--
Michael