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

[Florian Forster]

Hi Tobi,

On Wed, Apr 08, 2009 at 06:27:33PM +0200, Tobias Oetiker wrote:
> well in the sense that no 'secret' information can get out ... but you
> may remember that I raised this question right when the whole daemon
> thing started ...

yes, I do remember. And my position on that today is the same it was
then. If your bike is stolen because you didn't lock it down, no
insurance company will pay up because *it's your own damn fault!*

If your parents are suddenly grand-parents because you were too busy to
get some action to think straight, *it's your own damn fault!*

If all your data is destroyed because you left an unauthenticated,
unencrypted service open to the world and don't have a backup *it's your
own damn fault!*

Shipping wireless LAN access points without encryption to end-users is
not okay. But we're not talking end-user here, we're talking about
people who have the need to update *many* RRD-files, in the magnitude of
thousands!

> 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.

> 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.

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.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090408/661f684a/attachment.bin