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

Re: SSL configure patch: review

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Abhijit Menon-Sen <ams(at)oryx(dot)com>, pgsql(at)mohawksoft(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSL configure patch: review
Date: 2008-08-01 20:31:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> BTW, doesn't this patch leak memory at freePGconn() time?

Doh -- right, fixed.

> I also think that more of it should be inside #ifdef USE_SSL --- ie,
> the options should be treated like requiressl not sslmode, and not
> exist in a non-SSL build.

I wondered about that too, and couldn't make up my mind about it.  
This patch does things that way.

Something that's bothering me is that PGSSLKEY is inconsistent with the
sslkey conninfo parameter.  PGSSLKEY specifies an engine (basically a
driver for specialized hardware AFAICT) from which the key is to be
loaded, but sslkey is a simple filename.  This means that there's no way
to load a key from hardware if you want to specify it per connection.
Not that I have any such hardware, but it looks bogus.

Obviously one still wants to be able to specify a different file name
from the default; I tried to see if there's any way to load an engine
that would load the key from a file, but could not extract any sense
from the man page:

Maybe this means that we should provide separate parameters, say
"sslkey" and "sslkeyfile", and a new env var PGSSLKEYFILE.

Thoughts?  Am I overengineering this stuff?

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment: ssl-new-params-2.patch
Description: text/x-diff (9.9 KB)

In response to


pgsql-hackers by date

Next:From: Robert LorDate: 2008-08-01 20:42:23
Subject: Re: Review: DTrace probes (merged version) ver_03
Previous:From: Alvaro HerreraDate: 2008-08-01 20:01:37
Subject: Re: Review: DTrace probes (merged version) ver_03

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