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/
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
