Skip site navigation (1) Skip section navigation (2)

Re: TODO: GNU TLS

From: David Boreham <david_list(at)boreham(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, mark(at)mark(dot)mielke(dot)cc, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Subject: Re: TODO: GNU TLS
Date: 2007-01-02 19:25:34
Message-ID: 459AB1AE.3010106@boreham.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Stephen Frost wrote:

>>Also, do we really want to import the NSPR into Postgres? I suspect not. 
>>Of course, the only thing that people are tripping over license-wise is 
>>libpq. But I think we would want to keep that as lean and mean as 
>>possible, too.
>>    
>>
>
>erm, I'm not really sure what you're saying here but perhaps I can
>clarify:  I wasn't suggesting to add any serious amount of source code
>to PostgreSQL - NSS would be used just as OpenSSL is today, and as 
>GNUTLS support was proposed, a seperate library which is distributed 
>independently of PostgreSQL but can be compiled against.  I don't know
>
>  
>
I suspect that Andrew was concerned about the dependency NSS has on NSPR.
NSS dates back to the days before universal support for threads and mutexes.
NSPR was (is) a library designed to abstract platform differences in 
those areas,
and to provide its own implementations where none was available in the 
OS (e.g.
old MacOS, 16-bit Windows). So for example if you want to open an SSL 
connection
using NSS you get to hand it an NSPR socket handle, not an OS socket 
(however,
there are functions that allow construction of one from the other). For 
an application
that has otherwise no need for cross-platform service abstraction, or 
that has already
solved the problems NSPR solves in a different way, NSPR looks
like a big ball of goo that you don't need.  NSS can't exist in an 
application without NSPR.

Having said that, except in the case of cooperative threading 
environments (do those
exist today??), there's no requirement on the application to actually 
use NSPR for
anything other than plumbing underneath NSS.

Applications that want to handle their own I/O underneath the SSL library
(particularly useful in servers) will often not be happy with NSS due to its
layering above NSPR I/O.











In response to

Responses

pgsql-hackers by date

Next:From: Casey DuncanDate: 2007-01-02 19:43:54
Subject: Re: [PATCHES] xlog directory at initdb time
Previous:From: Stephen FrostDate: 2007-01-02 19:21:38
Subject: Re: TODO: GNU TLS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group