From: Andres Freund <andres@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Date: Tue, 19 Aug 2014 18:05:54 +0200
Message-ID: <20140819160554.GD30525@awork2.anarazel.de> (raw)
In-Reply-To: <20140819155237.GE16422@tamriel.snowman.net>
References: <53F1E989.8020609@vmware.com>
<20140819144841.GA16422@tamriel.snowman.net>
<20140819145547.GB30525@awork2.anarazel.de>
<20140819150507.GB16422@tamriel.snowman.net>
<20140819152613.GC30525@awork2.anarazel.de>
<20140819155237.GE16422@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2014-08-19 11:52:37 -0400, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > No. We should build something that's suitable for postgres, not
> > something general. We'll fail otherwise. For anything fancy the user has
> > to look at the certificate themselves. We should make it easy to get at
> > the whole certificate chain in a consistent manner.
>
> I don't buy this argument at all.
Aha.
> > > Telling users they simply can't have this information isn't
> > > acceptable.
> >
> > Meh. Why? Most of that isn't something a normal libpq user is going to
> > need.
>
> I'm not interested in SSL support for users who don't use or care about
> SSL (which would be 'normal libpq users', really).
That's the majority of our users. Even those that care about ssl care
about setting it up in a safe manner, won't care about most of the
attributes.
I have no problem to expand the list of attributes once we have a couple
of differing backends for the support, but having a long list of things
that need to be supported by every one just makes getting there harder.
> I've *long* been
> frustrated by our poor support of SSL and at how painful it is to get
> proper SSL working- and it's been a real problem getting PG to pass the
> security compliance requirements because of that poor support. Let's
> stop the rhetoric that PG doesn't need anything but the most basic
> SSL/auditing/security capabilities.
I've no problem with keeping future extensions of the API in mind while
this is being designed. We just shouldn't start too big. This is about
getting a proper abstraction in place, not making pg pass security
compliance stuff. Don't mix those too much.
> > > 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.
> >
> > I'm pretty sure that we can't build a reasonable list of the information
> > exposed by any library. Especially as we're likely going to need some
> > mapping to agree to map to the common names.
>
> Per Apache's documentation, mod_ssl and mod_gnutls support the same set
> of environment variables (with the same names even), so I don't buy this
> argument either.
Gnutls is quite similar from what it provides to openssl. That's not
saying much. Schannel would be more interesting from that point of view.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@2ndquadrant.com, sfrost@snowman.net, hlinnakangas@vmware.com
Subject: Re: PQgetssl() and alternative SSL implementations
In-Reply-To: <20140819160554.GD30525@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox