On Mon, Jun 09, 2014 at 11:39:17PM +0900, MauMau wrote:
> From: "Heikki Linnakangas" <hlinnakan...@vmware.com>
> >Thoughts? While we're at it, we'll probably want to refactor
> >things so that it's easy to support other SSL implementations too,
> >like gnutls.
> 
> That may be good because it provides users with choices.  But I
> wonder if it is worth the complexity and maintainability of
> PostgreSQL code.

The complexity is very low. SSL is a standard protocol and so all
libraries offer the same functionality. Were not really doing anything
complex.

> * Are SChannel and other libraries more secure than OpenSSL?  IIRC,
> recently I read in the news that GnuTLS had a vulnerability.
> OpenSSL is probably the most widely used library, and many people
> are getting more interested in its quality.  I expect the quality
> will improve thanks to the help from The Linux foundation and other
> organizations/researchers.

Does that matter? What's wrong with letting people choose. OpenVPN
these days supports multiple SSL libraries, because PolarSSL (for
example) has been vetted for a higher security level than OpenSSL.

> * Do other libraries get support from commercial vendor product
> support? For example, Safenet Inc., the famous HSM (hardware
> security module) vendor, supports OpenSSL to access the private key
> stored in its HSM product.  Intel offered AES-NI implementation code
> to OpenSSL community.  I guess OpenSSL will continue to be the most
> functional and obtain the widest adoption and support.

And the crappiest license. I think it's silly for PostgreSQL dictate
what SSL library users must use, when there are so many possibilities. 
We also support libedit for, in my opinion, worse reasons.

Have a nice day,
-- 
Martijn van Oosterhout   <klep...@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

Attachment: signature.asc
Description: Digital signature

Reply via email to