Alex Hunsaker wrote:
> On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera <alvherre@commandprompt.com> wrote:
>> 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:
>> http://www.openssl.org/docs/crypto/engine.html
>>
>> 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?
>
> I think the patch as it stands is ok for now (mainly because I don't
> have any hardware either so I can't test or attest to how it should be
> done i.e. if those params would be enough)
>
> Should PGROOTCERT be PGSSLROOTCERT to be more congruent with all the
> other ssl params?
Yes, I think that'd be a good idea.
> Find attached an updated patch against HEAD (no other changes). I
> also gave it a look over and tested it to make sure it worked as
> described.
I still think the parameters should be available for non-SSL builds, but
ignored. None of them put any restrictions in place, so it's not an
issue to ignore them if we are not going to obey them (if SSL isn't used
anyway), and it'll make life easier for autogenerated connection strings.
I also think we should rename the variables internally. conn->sslcert
sounds very much to me like it'd be the certificate in use for the
connection, which it isn't. How about "sslcertname", "sslcrlname" etc?
(no need to change the user visible stuff, just in the code to make it
easier to follow elsewhere)
We still have the issue with the environment variable not matching the
connection string one that needs to be resolved.
Thoughts?
(I have added this to the commitfest page, as it was lost)
//Magnus