[rrd-developers] [RRDCacheD] Authentication (was: Why / How / When is version 1.2 developed?)

[Tobias Oetiker]

Hi Florian,

Yesterday Florian Forster wrote:

> > my problem is that in the end my name is tied with rrdtool and people
> > WILL use it unresponsible and wrongly ... I am sure ... so if we do
> > not even provide security this might be a PR night mare for me ...
> > which I would rather avoid
>
> I have to admit that this statement makes me angry. I've avoided
> replying to your previous statement for precisely this reason, but since
> you keep pushing that point I feel I have to comment.
>
> The mere fact that you justify your point with fear about your good name
> is an affront towards Kevin and me, the actual authors of the software
> in question, as it seems to imply that you intend to take credit for our
> work.
>
> Maybe it'd be for the best if we removed ?rrdcached? from the ?RRDtool?
> sources again and I was developing it as a separate project again. The
> ?rrdc_*? functions would be provided by a client library which could be
> used by ?RRDtool? if available. Just say the word and I'll provide a
> patch.

I love the rrdcached functionality and all the work you did on it
and I would not want to miss it.

But it also makes me sad to see you angry or unhappy. So if you
feel that it is better for you to run your own show, I am perfectly
ok with you doing a fork of the cache daemon and hooking it up to
librrd. This will give you the freedom to develop it in any
direction you feel is sensible.

> > no problem, with making it more complete, for 1.4 I am happy with
> > authentication by shared secret. As for ssl support I would want to
> > make sure that openssl is optional (as is starttls).
>
> I still think authentication without encryption is worthless and the
> root of *much* more evil then stating clear and without any doubt that
> there is no security built-in.
>
> Implementing only SSL support would be by far preferable over
> unencrypted shared secret authentication, because it'd give you
> authentication via certificates for free.

see my anwer to kevins mail.

> I'm also a bit disappointed that you didn't comment on the ?en-/dis-
> able only specific commands for each socket? as it's an easy to
> implement solution that addresses the mentioned issues by offering the
> user a choice ? the way it ought to be.

> No substitution for encryption
> and authentication, of course, but people who feel like you do could
> simply disable ?FETCH? and the problem (whatever it may actually be) is
> vanished.

sorry ... I just had not comment on this ... from what you wrote it
does sound fine, its just that in my tiny world, all I would need
to setup a sensible system, in line with the rest of your security
model is that as a remote host is sending his updates to a central
host we can be reasonably sure, it is 'our' rrdtool on that other
host, sending the data.

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900
;