Re: [PATCH] Automatic client certificate selection support for libpq v1

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Seth Robertson <in-pgsql-hackers(at)baka(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Automatic client certificate selection support for libpq v1
Date: 2009-05-11 08:09:33
Message-ID: 4A07DD3D.2010602@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Seth Robertson wrote:
> In message <14727(dot)1241816192(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane writes:
>
> > It is of course possible to support both at the same time (at
> > compile-time, if nowhere else).
>
> Yes, I suppose we'd not wish to just drop openssl completely.
> I wonder how much code duplication would ensue from a compile-time
> choice of which library to use ...
>
> My only datapoint for you is curl, which is an application I happen to
> have discovered that can use either NSS and OpenSSL.
>
> Lines Words Chars Filename
> 2508 7890 74682 ssluse.c
> 1331 3708 36411 nss.c

IIRC, they also support gnutls. So we can probably get hints there about
how to get this support if we want to :-)

> I imagine that you would more or less have to provide a different
> be-secure.c and fe-secure.c file for the two different
> libraries--whether as a separate file or via #ifdefs. It looks like
> there is a small amount of common code present (why *is*
> pg_block_sigpipe() in that file anyway?)

Clearly this would be a good time to fix such abstraction errors if we
decide to go ahead :-)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hans-Juergen Schoenig 2009-05-11 08:26:52 SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Previous Message Magnus Hagander 2009-05-11 08:06:24 Re: SSL cert chains patch