pcp
[Top] [All Lists]

Re: PCP Updates: Fix Bug #1035: PMCD Should Not Fail to Start if NSS Fai

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: Re: PCP Updates: Fix Bug #1035: PMCD Should Not Fail to Start if NSS Fails to Initialize
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Tue, 25 Mar 2014 13:56:02 -0400
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0m7g7i8bx2.fsf@xxxxxxxx>
References: <53319A17.6060608@xxxxxxxxxx> <y0m7g7i8bx2.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 03/25/2014 12:45 PM, Frank Ch. Eigler wrote:
Dave Brolley <brolley@xxxxxxxxxx> writes:

commit b9d2adfa5ae7cc5d8ef8416bbf804736a40efda5
Author: Dave Brolley <brolley@xxxxxxxxxx>
Date:   Tue Mar 25 10:35:25 2014 -0400

     When NSS fails to initialize, pmcd should still start successfully.
[...]
Have you considered doing this at the pmcd/pmproxy.c level instead, so
that a bad rc from __pmSecureServerSetup is sent but tolerated
(instead of triggering DontStart())?  That way, the
__pmSecureServerSetup function doesn't lie about its success, which in
turn would later let us extend pmcd with a $PCP_SECURE_SOCKETS-like
option to *require* ssl?

I did think of this and still think that within libpcp is the best place for this change. I thought that there might possibly be a future reason (like your example) for __pmSecureServerSetup() to fail in a fatal way. The current implementation does allow for this. I don't see it as __pmSecureServerSetup() lying. There was already a case (no server certificates exist at all) for which it was returning 0. I took this to mean that a return code of zero was not asserting that the setup was completely successful, just that the problem was not fatal.

Dave

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