On 21 June 2012 02:46, Dave Brolley <brolley@xxxxxxxxxx> wrote:
> I have been given the assignment of adding SSL/TLS capability to the various
> components of PCP.
Thanks for looking into this. Diving straight in with random comments here...
> This would give clients and agents the option of using a
> secure connection with the pmcd if desired. Having started the work, I
While the pmcd/client channel I can definitely see needing encryption at times,
I'm not sure there is any case where pmcd/pmda channels would ever need it.
The pmdas are all (most always) children of pmcd, always on the same host.
> All of the work described below can be found on the brolley/nss branch in
> our pcp repository at git://sourceware.org/git/pcpfans.git
Had a quick look, & will look deeper when I get some time. I was trying (but
failed) to see how a client tool chooses to enable an encrypted channel, and
I didn't really follow from the rest of your mail whether thats been considered
Assuming we are going to keep the option for clients to establish non-secure
channels (which I really think we have to), then we'll need a mechanism at
several points to say what type of connection its to be. I suspect this means,
for example, that pmNewContext(3) would need to acquire a new "type" -
PM_CONTEXT_SECURE? - as an alternative to PM_CONTEXT_HOST. This
new type would need to be exposed to the user then, depending on the tool.
For command line tools, __pmParseHostSpec could perhaps be extended to
allow for a connection-type prefix - eg. "pcp://host.name.com" vs a secure
variant "pcps://host.name.com". The pmHostSpec structure would have to
acquire a flag field, and that flag would then be used in the client
tool code to
set the appropriate pmNewContext type. pmParseMetricSpec(3) would need
For graphical tools like pmchart, the New Host dialog could have a lock radio
button or something similar, and the user could select which way to establish
the connection directly through the UI.
Well, that might be one way to go anyway, is that the kind of thing you were
imagining would be needed or is none of this necessary somehow?
> .... In this way
> existing pmcd clients and agents can still connect to pmcd without change
> and future clients and agents can still use insecure connections if they
(good stuff, I think we have to consider that as a non-negotiable requirement)
> Once I have both sides of the abstraction implemented, testing will be the
> next area of focus. I understand that there is a test harness at
> I will likely need help in getting things set up on my available platforms
> and will certainly need assistance in testing on platforms that are not
> available to me.
I can help with that when you get to that point. Grab me on IRC (#pcp
on freenode) or ping me via mail when you're ready to start that and I'll
take you through it.
> I would appreciate feedback on the approach and on the abstractions that
> have been made so far. Have I placed the abstraction at the correct level
> and place within the system? Is the work headed in the right direction for
I haven't gone through the code in great detail yet, but from your description
it sounds unavoidably invasive - abstracting does seem like the best way to
deal with that and minimise risk of regression. I'll dig deeper when I get a
bit more time, and provide some more useful feedback. OOC, there is an
"ssl" branch in pcpfans too - does that need to be reviewed in tandem with
this "nss" branch? thanks.