pcp
[Top] [All Lists]

Re: pcp updates - overcome secure sockets breakage

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pcp updates - overcome secure sockets breakage
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 23 Apr 2013 09:42:44 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <51762D9B.3090702@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Tue, 23 Apr 2013 16:43:39 +1000")
References: <51762D9B.3090702@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
kenj wrote:

> [...]
>     Introduce $PCP_SECURE_DB_METHOD environment var
>     
>     This is an attempt to overcome the problems associated with
>     hardcoding the sql: method into the certificate and key database
>     management, which fails badly on older platforms [...]

Understood.

>     Note that $NSS_DEFAULT_DB_TYPE is not an option as this apparently
>     intended for compatibility support in the other direction,
>     as "sql" appears to be the only well-defined value for this
>     environment variable to enable the "new" method.

Can you elaborate please?  The model of this variable is that even if
it is set to "sql" (with certificate file names unadorned by the sql:
prefix), older versions of NSS such as on RHEL5 will ignore it, and
use plain berkeleydb data files.  Current versions of NSS will use it
as an implicit prefix.  What's not suitable about this?

(I believe nathans was going to test modern NSS's behavior about its
run-time searching behavior, in case sql: or non-sql: databases are
found in its target directory.  It may turn out that this
$NSS_DEFAULT_DB_TYPE-or-equivalent need only be specified
once: at certificate db creation time.)

- FChE

<Prev in Thread] Current Thread [Next in Thread>