Re: PQgetssl() and alternative SSL implementations

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: PQgetssl() and alternative SSL implementations
Дата
Msg-id CABUevEzfxyOqWsWiVH6=hMfWx--sgCyqzR=2EvLQCwz==XuSZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PQgetssl() and alternative SSL implementations  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Tue, Aug 19, 2014 at 5:05 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
>> On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
>> > At first blush, I'd say a whole bunch..  Off the top of my head I can
>> > think of:
>
> [...]
>
>> I'm not really sure we need all that. We're not building a general ssl
>> library abstraction here.
>
> Really?  I'm pretty sure that's exactly what we're doing.  What I was
> wondering is which one we should be modeling off of.
>
> One thought I had was to look at what Apache's mod_ssl provides, which
> can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
>
> I know that I've used quite a few of those.
>
> Telling users they simply can't have this information isn't acceptable.
> I'm not a huge fan of just passing back all of the certificates and
> making the user extract out the information themselves, but if it comes
> down to it then that's at least better than removing any ability to get
> at that information.

Yeah, being able to provide most of them easily accessible is a good
thing. Otherwise, we just move the burden to deparse them to the
client which will then have to know which SSL library it's built
against, so every single client that wants to do something useful with
the cert would have to know about multiple implementations.

I think starting from the apache list is a very good idea.

We should then expose the same set of data at least through the
sslinfo server module.


>> What I'm wondering is whether we should differentiate 'standard'
>> attributes that we require from ones that a library can supply
>> optionally. If we don't we'll have difficulty enlarging the 'standard'
>> set over time.
>
> If we end up not being able to provide everything for all of the
> libraries we support then perhaps we can document which are available
> from all of them, but I'd hope the list of "only in X" is pretty small.

+1. I bet the most common ones will be in all of them, because
frankly, it's functionality you just need to use SSL properly.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: PQgetssl() and alternative SSL implementations