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

Re: OpenSSL Applink

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Dave Page <dpage(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: OpenSSL Applink
Date: 2007-10-03 19:16:23
Message-ID: 4703EA87.6010907@hagander.net (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> I guess you guys already found a solution that works, but there's yet
>> another function, "BIO *BIO_new_mem_buf(void *data, int len)", that we
>> could use. We could open and read the file all by ourselves into memory,
>> then call BIO_new_mem_buf and pass that to PEM_read_X509. No need to
>> pass around file pointers, and we could handle any file I/O errors
>> ourselves. Presumably certificates are never very big, so reading it all
>> in memory shouldn't be a problem.
> 
>> BIO_new_mem_buf was introduced in OpenSSL 0.9.7. What versions do we
>> support?
> 
> This seems like a good idea.  To judge from the release history at
> http://www.openssl.org/news/
> the OpenSSL boys stopped supporting 0.9.6 in 2004, so I figure we
> don't have to support it either.  But 0.9.7 is still a live release
> branch, so it'd be good if we could play nice with it.
> 
> http://www.openssl.org/docs/crypto/BIO_s_mem.html

Not sure it buys us much more than we already have. Sure, we can handle
file I/O. But we still can't handle errors in the parsing of the file.

I think that if we can open the file, then the chance that we fail to
read it is extremely small, compared to the chance that we get a parsing
error.

//Magnus

In response to

pgsql-patches by date

Next:From: Brendan JurdDate: 2007-10-03 22:27:50
Subject: Use of "postmaster"
Previous:From: Tom LaneDate: 2007-10-03 17:58:23
Subject: Re: OpenSSL Applink

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